Adapt to platform-specific threading constraints

Certain .NET runtime environments impose significant constraints on the use of threads. For example, in Blazor WASM, you can encounter `PlatformNotSupportedException` when trying to use normal .NET threading APIs. In Unity, there are constraints around how threads and timers should interact.

In the early days of Rx.NET, this sort of problem could sometimes be addressed through the fact that different platforms required different binaries, and so we could use conditional compilation to bake in suitable platform-specific behaviour. But the "One .NET" vision (dating back to .NET 5.0, I think) was that there should be just one runtime, discouraging us from having different binaries for different environments.

In fact, that wasn't even the first initiative along those lines. We have .NET Standard and before that PCLs, which touch on the same issues (although not necessarily with exactly the same motivations; .NET Standard was really all about creating a viable path for getting off .NET FX and onto .NET (Core)). Back in the PCL days, Rx.NET did introduce a mechanism design to cope with the fact that you wouldn't necessarily know at build time what environment code would end up running in. The `IPlatformEnlightenmentProvider` interface addresses this issue.

We would like `System.Reactive` to be a good choice for Unity, and we know that it is currently problematic. And we also want it to work well for WASM. So we need to be able to adapt to different threading requirements (and perhaps other environment-specific considerations).

We need to investigate whether the `IPlatformEnlightenmentProvider` mechanism is a good fit for this. It might not be: the original thinking behind that was that it provided a way to _improve_ operation by adding in platform-specific-awareness, but that it wasn't strictly necessary to have it: the library would build in lowest common denominator behaviour, but a suitable `IPlatformEnlightenmentProvider` might provide replace this with something optimized for a particular platform. But the problems I'm describing here aren't merely poor performance: things are actually broken on certain platforms. Perhaps `IPlatformEnlightenmentProvider` will be able to help with this but perhaps we need something else.

Some related issues and comments: #2061, #1628, https://github.com/dotnet/reactive/pull/1879#issuecomment-3822971830