Allow obtaining serializable tokens that represent JoinableTasks

[AArnott]

To enable RPC calls (e.g. JSON-RPC -- not COM calls), we add two new APIs:

1. string? JoinableTaskContext.Capture() - returns a token that represents the JoinableTask that is currently running, and its tokenized parents.
2. JoinableTask JoinableTaskFactory.RunAsync(Func<Task>, string?, JoinableTaskCreationOptions) - applies a token previously obtained from any Capture() call (even from another process) so that any JoinableTask context that matches this JoinableTaskContext object will be applied as a parent to the new JoinableTask.

Together, this allows RPC infrastructure to utilize JoinableTaskFactory to mitigate deadlocks due to requirements on the same UI thread that would otherwise be undetectable as dependencies due to how RPC runs its own queues, and may weave in and out of the process.

Prior to merging:

• Prepare changes to StreamJsonRpc that consumes these new APIs to validate that the E2E works.
• Add more xml doc comments, and any more code comments that are appropriate.
• Return null from Capture() when the JoinableTaskContext is in 'no main thread' mode.

[lifengl]

those changes look good to me.

[lifengl]

One potential thing to consider is that we don't need inject the JTF context into the chain, if the current JTF context has no UI thread. I am not sure this is doable in the JTF side, or you want to leave it to StreamJsonRpc (i guess it is tricky to know that state in StreamJsonRpc), that will allow us to prevent this cost on services which has JTF just to run code in the compatible way, (and I guess most services do not have UI thread), so it could limit the context string to include a single or very few contextId in the real world even the call chain passes through several layers?

[AArnott]

Yes, I'll look into making Capture() return null when the JoinableTaskContext is in 'no main thread' mode.