Add IRuntime in Future context

[DragonFrai]

Various operations may depend on the current scheduler, or in general, runtime (a concept more extensible than the scheduler and not tied to it). For example, delay or wrapping synchronous I/O. Potentially, these more optimal implementations can be provided through runtime than through the standard asynchronous dotnet API. In addition, this will allow you to throw through the unique capabilities of runtime, although this will require dynamic determination of their capabilities, but sometimes this can be useful.
This has always been the reason for adding the scheduler to the Future context. There was also a reason for the really parallel launch of Future. But he looks completely clumsy there. And the allocation of runtime will allow you to more explicitly express the absence of a scheduler and, for example, call merge instead of running in parallel.

Context subtypes can also be a solution

An alternative solution would be to simply remove the scheduler from the context and not add a new entity and implement all the basic operations through the asynchronous dotnet API.
A similar mechanism can be implemented by binding information about the execution context via ThreadLocal, bypassing explicit transfer. This will allow to provide implementations tied to the runtime, but a general universal solution will most likely have to be avoided.