Include transient and speculative WFT events in GetWorkflowExecutionHistory response (#7732)

## What changed?
Include transient and speculative WFT events in
`GetWorkflowExecutionHistory` response. UI and CLI doesn't support such
events, and they are not included if client it detected as UI or CLI.

Because `TransientWorkflowTaskInfo` is now loaded from mutable state,
there is no need to store it in continuation token and pass between
services: these fields are removed from the token and all internal RPC
request/response messages.

## Why?
Previously, transient and speculative WFT events were included only in
the history which is attached to WFT itself. But if history is requested
using `GetWorkflowExecutionHistory` API then it didn't have these
events. Worker requests full history when Workflow is idle for a long
time and got evicted from the cache. In this case, it causes WFT to fail
with message like:
```
history_events: premature end of stream, expectedLastEventID=3713 but no more events after eventID=3711
```
Retries prevent Workflow from stuck but with extra `WorkflowTaskFailed`
event in the history.

## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [x] covered by existing tests
- [x] added new unit test(s)
- [ ] added new functional test(s)

## Potential risks
This is a potentially risky change because it change a contract between
server and worker. This change is a "bug fix" but there might be
[unforeseen
consequences](https://strategywiki.org/wiki/Half-Life/Unforeseen_Consequences)
in some worker behaviours.

Also during rollback `TransientWorkflowTaskInfo` won't be in the token
and RPC and will cause another failure of WFT in cases when worker need
to paginate over history. But since WFT is already failing this
shouldn't be a big problem (if any).

Author: alexshtin