Move options related types that are linked into CodeStyle layer to a different namespace to avoid type name conflicts

Closes #41260

* CodeStyle+Workspaces -> CompilerExtensions
* CodeStyle+Features -> Analyzers
* CodeStyleFixes+Workspaces -> WorkspaceExtensions
* CodeStyleFixes+Features -> CodeFixes

* Move IndentationService down to Feature layer.

* MOve to workspaces

* Cleanup

* Fix.

* move ISmartTokenFormatter down as well

* simplify

* Get building

* Update

* Move using inside

* Move using inside

* Move using inside

* Move using inside

* Add links

.Net - .NET

Fixes #27685

This ports https://github.com/dotnet/roslyn/pull/28472, that went into the `editorconfig-ide` feature branch, into `dev16.0.x` branch with following additional refactorings/enhancements:

1. Generated .editorconfig file has all localized string as comments.
2. No hardcoding of individual options in the editorconfig file generator. Instead, each `EditorConfigStorageLocation` now requires to provide a delegate to convert a given option value into the .editorconfig string representation (basically complimentary of the parsing delegate that was already required).
3. Introduce concept of `OptionGroup` to enable grouping options in the same feature (such as CodeStyleOptions, CSharpCodeStyleOptions, FormattingOptions, CSharpFormattingOptions, etc.) into sub-features or groups (such as "this. preferences", "expression-level preferences", etc.). This enables the editorconfig generation to group the related options, without explicit knowledge of each option group.
4. Expose `AllOptions` from each option feature (such as CodeStyleOptions, CSharpCodeStyleOptions, FormattingOptions, CSharpFormattingOptions, etc.), so that the corresponding `IOptionProvider` always stays in sync with implemented options.

- Don't expose the lambda back out
- Make a default case so you don't have to specify a lambda at all
  for common things like bool or int

Now that feature names aren't used for serialization anymore, we can
just get rid of the constants and use the containing type name.
Also, update more options to use nameof where appropriate.

Now that we have an API for associating persistence information,
we can put that information on all our options we persist today.
We'll consume this in a future commit.

Fix #2218 Language Settings Serializers should not be used to serialize
Non-PerLangaugeOptions. This change addresses this issue

Remove UseTabOnlyForIndentation since this is a public option & there
are no testcases for this option. With the changes the option is no
longer used making it obsolete. Fix the broken testcase which was
asserting the undesired behavior

This change splits the Workspaces layer into two parts, mirroring the Portable/Desktop split that the compilers did. The core parts of the Workspaces layer (managing documents and projects, formatting, some refactoring, code fixes) is kept in the portable subset, with a few non-portable pieces remaining, notably MSBuild support.

This change has a major impact on how MEF now works in Roslyn. Traditional MEF (“MEFv1”) is not portable, and so we must move the Workspaces layer over to using the Microsoft.Composition NuGet package (“MEFv2”) which is. The APIs are distinct in that each has its own namespace, but the concepts are more or less identical. It requires some care though: the workspaces layer is simple in that it only references MEFv2, but higher layers have to reference both versions to use metadata attributes. Exports using metadata attributes from the editor (say, ContentTypeAttribute) must use MEFv1 attributes to export, whereas exports for the workspaces layer must use MEFv2 attributes. The rule is subtle and yet simple, and so a diagnostic is provided which catches any offenses to prevent confusion.

This also has some impact in how we create MEF hosts: if you wish to host just the base workspaces layer, we can use MEFv2 to compose everything. The HostServices implementation (MefV1HostServices) that consumes a MEFv1 ExportProvider. If you’re in Visual Studio, you can use this implementation to get the full set of host services provided in Visual Studio.

Otherwise, most of the changes in here are minor: we react to some APIs that have been moved/renamed in the portable subset we are targeting, and also align our various exception helper utilities with the compiler’s precedent. (changeset 1349276)

Introduce an option, ShouldUseFormattingSpanCollapse,  to tell the formatting engine if it should collapse the formatting spans if there are more than 30 spans to be formatted(Collapsing involes taking the a bunch of spans and returning one span whose startingPoint is startingPoint of the first span and the ending point is the endpoint of the last span in the bunch). The default value is to not collapse

There are few CodeFix Provider which act on the whole document for which the formatting engine will collapse the spans to one span.

In order  to improve telemetry, I have introduced some new CodeActions instead of using the generic Document/SolutionChangeCodeAction (changeset 1317739)