[Feature Request] Attach info about unresolved commands to WFT completions

Is your feature request related to a problem? Please describe.

Right now, there is no way when inspecting workflow history to tell if the workflow is actually waiting on something to be resolved (ex: receive a signal) or is completely stuck and will never be able to make progress.

Beyond that, it is immediately obvious how useful it would be to know things like "Oh, I am WFT heartbeating because I'm waiting on a local activity". Or "This workflow is currently waiting on two signals", etc etc.

Describe the solution you'd like

We should add a new field to workflow task completions which allows us to record this information. Possibly, it makes good sense to just have a generic map field, so that we can record anything SDKs feel like without needing to go back and add a new field each time. However, it does make good sense to make the value we record be a proto so that it can be viewed in the UI.

We should record:

• Number of executing local activities
• Counts of how many of each thing that can be awaited are actively being awaited (signals, activities, timers, children, etc)

This will allow us to understand why a workflow completed a task with no commands. If it's not waiting on anything, then by definition the workflow is now stuck. Detecting this situation and alerting the user would be incredibly useful.

No files or tests are named. Start by tracing workflow task completion handling across the SDKs and the UI concerns described here, then define the completion field and the awaited-work counts; done means unresolved commands and waiting reasons can be recorded and viewed consistently.