Exposing workflow code position for decisions in history events

[longquanzheng]

This is for improving debuggability/userability of Cadence: for each decision result(schedule activities/timer/childWF etc), put the code position that generating that decision. It will be very useful to debug(like non-deterministic error) workflow when looking at history, and also make it much easier to use workflow reset.

It's quite simple to implement in client most languages(go/java/python)-- simply get it from the calling stack when schedule the activities/timer/childWF etc, and response with decision result.

People may have concerns like performance for getting call stack. We can:

1. Have benchmark to see how much impact. In theory should be small, since decision processing is more costly at RPC calls.
2. Make it a config flag on the client to let customer decide to turn in on/off.

These information will lower the bar for using Cadence. Customers and even Cadence engineers will feel more comfortable when debugging. And it gives possibility to make some plugins in IDE to make it seamless.

[longquanzheng]

@mfateev mentions that we could also provide query on decisions(by ID) to get calling stack. This could also help as well. It's just less friendly because it requires worker and cadence server to run. It's less useful if you don't have the the environment setup.
But we could do both. if we do see perf impact with my approach, we can take this approach in production.