Rework some F# layering

[KevinRansom]

I intend to try to refactor F# core into at least two assemblies.

1. fscorlib --- Core types supporting runtime scenarios
2. FSharp.Core --- Types supporting runtime and compilation scenarios

The benefit of this is that we can build a platform specific fscorlib.dll and deploy it with each new runtime, so we can start to use new runtime features in our core library. I have no idea how successful this will be whilst retaining compatibility, but I really want to give it a solid try.

This PR

• Renames the config setting compilingFSharpCore to compilingCoreLibrary

Eliminate compiler reliance on ExtraTopLevelOperators modules, because it pulls types from all over FSharp.Core

• Add ExtraTopLevelOperators to Operators and Operators.Checked
• Tests for added Operators and Operators.Checked
• Hides ExtraTopLevelOperators for moved operations from intellisense
• Move dict and set implementations to Collections namespace
• Move Printf
• Move DefaultAsyncBuilder
• Move Measures
• Ensure Compiler only uses the above from their new locations

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/FSharp.Core	docs/release-notes/.FSharp.Core/9.0.100.md
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/9.0.100.md

[github-actions]

Caution

Repository is on lockdown for maintenance, all merges are on hold.

[edgarfgp]

Was wondering if Deprecate limitedHash functionality with next major version of Fsharp.Core fsharp/fslang-suggestions#1230 can be implemented as part of this work ? .

[vzarytovskii]

Was wondering if `Deprecate limitedHash functionality with next major version of Fsharp.Core

` fsharp/fslang-suggestions#1230 can be implemented as part of this work ? .

It might. But this won't make it in 9. Too many changes to include it now.