Save and restore ExecutionContext for runtime async calls

[jakobbotsch]

Add support for saving and restoring the ExecutionContext around runtime async calls. Most of this is done in the JIT:

• For task awaits, ExecutionContext is stored on both synchronous and asynchronous (suspending/resuming) paths. The JIT inserts IR between import and inlining to save the context before each async call, and to restore it after. If the call is inside a try clause, then this requires insertion of a try-finally to ensure the context is restored even if an exception is thrown.
• For custom awaits, ExecutionContext is saved and restored only in the asynchronous path. Thus the JIT only saves/restores the context as part of the suspend/resume paths.

For the first case above we allow inlining the helpers. The second case above happens too late to rely on normal inlining, so right now it just inserts calls to two helpers. In the future we can consider inlining these manually in the suspend/restore paths.

For runtime async calls we assume that Thread.t_currentThread is always initialized. This initialization happens as part of DispatchContinuations or the Task-returning thunks. So we can avoid calling InitializeCurrentThread when capturing/restoring the contexts. I have introduced a new Thread.CurrentThreadNoInit to access the TLS field without initialization.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[jakobbotsch]

cc @dotnet/jit-contrib PTAL @AndyAyersMS

[AndyAyersMS]

JIT changes LGTM. Left a few comments for your consideration.