This moves net6.0 to using the default thread pool for pipe scheduling rather than our scheduler. Namely due to 2 major changes since this was introduced:
1. Thread theft has long since been resolved (never an issue in .NET Core+)
2. Sync-over-async is an app problem, but should be much better in .NET 6.0+ which has changes specifically for this in thread pool growth (see https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/#threading)

Due to this combo of changes, we want to see if this behaves much better in the next alpha. The advantages are we move from 10 threads by default shared between connections to no dedicated threads for the scheduler. It has the following benfits:
1. While these threads were mostly idle (waiting for data), people saw them in profiler traces and attribute them as working/CPU-consuming though that's not what a profiler is really saying.
2. The default of 10 threads is a best guess, but the world varies widely. Some users are deploying many connections on 20-100 core VMs and it's a bad default limiting them (by default - not if configured). On the other end of the spectrum, a _lot_ of people run small 1-4 core VMs or containers and the default size is bigger than needed.

Instead of the above tradeoffs meant to unblock users, want to simplify, let the main threadpool scale, and hope the default is a net win for most or all users. If a consumer application has a _ton_ of sync-over-async (e.g. 100,000 tasks queued suddenly), this may be a net negative change for them - that's why we want to alpha and see how this behaves with workloads we may not have predicted.

"Image 'Visual Studio 2022' is not supported by the target cloud." Whatever...we'll change up the build later.

This method is sensitive to load, making it a bit less sensitive.

This allows for using new APIs introduced in net6.0.

In order to enable building for net6.0, we also need to revert the thread pool changes in StackExchange#1939 and StackExchange#1950. This was already effectively reverted in StackExchange#1992 by not building for net6.0. Now that we are building for net6.0 again, these if-defs need to be removed.

This allows for using new APIs introduced in net6.0.

In order to enable building for net6.0, we also need to revert the thread pool changes in #1939 and #1950. This was already effectively reverted in #1992 by not building for net6.0. Now that we are building for net6.0 again, these if-defs need to be removed.