适应平台特定的线程限制

某些 .NET 运行时环境对线程的使用设置了严格的限制。例如，在 Blazor 中，尝试使用普通的 .NET 线程 API 时可能会遇到 `PlatformNotSupportedException`。在 Unity 中，线程和定时器如何交互也有限制。在 Rx.NET 早期，这种问题有时可以通过不同平台需要不同的二进制文件来解决，因此我们可以通过条件编译将适当的平台特定行为添加到代码中。但是，`.NET One` 的愿景（可追溯到 .NET 5.0，我认为）是只有一个运行时，这阻止了我们为不同的环境生成不同的二进制文件。事实上，这甚至不是首个在这方面的倡议。我们有 .NET Standard 和之前的 PCL，它们都涉及到相同的问题（尽管可能不是完全出于相同的动机；.NET Standard 真正的目的是为从 .NET FX 切换到 .NET（Core）创造一个可行的路径）。在 PCL 时代，Rx.NET 确实引入了一个机制设计，以应对在编译时无法确定最终运行的环境代码的情况。`IPlatformEnlightenmentProvider` 接口解决了这个问题。我们希望 `System.Reactive` 对 Unity 来说是一个不错的选择，我们知道它目前存在问题。我们还希望它能够很好地适用于 WASM。因此，我们需要能够适应不同的线程要求（以及可能的其他环境特定考虑因素）。我们需要调查 `IPlatformEnlightenmentProvider` 机制是否适合此情况。它可能不是：该机制的最初设想是通过添加平台特定意识来改进操作，但并不绝对需要它：库将采用最低公共约数行为，但合适的 `IPlatformEnlightenmentProvider` 可能会将其替换为针对特定平台优化的内容。但是，我在这里描述的问题不仅仅是性能差：在某些平台上，事情实际上出了问题。也许 `IPlatformEnlightenmentProvider` 可以帮助解决这个问题，但也许我们需要其他方法。一些相关问题和评论：#2061，#1628，https://GitHub.com/dotnet/reactive/pull/1879#issuecomment-3822971830