Code Style: Analyzer/Fixer/Options for naming conventions 

Implements #7064

This change includes:

- An analyzer and codefix for enforcing naming styles and fixing symbol names to comply with a chosen & configurable set of naming rules.
- A set of Enforcement Levels that can be applied to different naming rules.
- A mechanism for linking from a lightbulb preview to the option that caused the related diagnostic to be created (could be moved to a different PR or release)
- Moving of the "Formatting" options pages under the Code Style node.

Consume new use var options from CodeGen features

This is part of #9155

Since, we replaced an existing user option about using var in local declarations with 3 new codestyle options, we need to update code generation features that were directly consuming these affected options.

This PR, selectively handles updating the consumers of the obsolete option and moving them over to use the new options.

.. new use var options. If you don't set options, you get default
options.

.. new use var options.

.. new use var options

.. the new use var codestyle options.

Reduce allocations for IsGeneratedCode analysis in the analyzer driver.

.. the new use var codestyle options.

... into a static helper class and share it at CSharpFeatures level.
This is the first step
towards getting the codegen features (introduce local, generate
variable) to be able
to use the new use var options correctly.

Implement a new options page for Code style features.

Part of #9155

Summary of changes:

1. Implements a new options page for code styles.
2. Brings the new use var code style into this page.
3. Brings existing code styles into this page.

Extra tests to cover combination of ref returns/locals and conditional access ( ?. ) operator.

.. the new CodeStyle options page.

..  Quick Launch bar

..  and remove dead code.

and reorder some members.

.. and comments that no longer apply.

.. the new CodeStyle options UI page.

Notes:
1. UseVarForDeclarations - the option used by some features isn't
onboard, it is to be replaced by the new use var options.

2. Since the existing options are part of public api, we keep the
options' data structure as such and map the type to a corresponding view
which is used to update the UI. Since they were all underlying boolean
options, we introduce a BooleanCodeStyleOptionViewModel that maps to a
CodeStyleOption type and back.

3. update the StyleViewModel to create options using these new view
models.

This adds the xaml and a view model and plugs everything in
to the current tools->options system.

Require prohibit this me

Use var codestyle updates

Part of #9155

Change summary:
Implements a fix all provider for the codestyle, and adds corresponding tests.
Fixes an oversight with previous implementation of detecting built-in types.

If the preference is set to "use explicit type for built-in type" and if
the code is non-compliant (uses var), then we need to flag this case and
offer a fix.

Basically, this adds to my definition of IsInIntrinsicContext. It is now
either that the declaration has a predefined type or the declaration
type is inferred and the inferred type is an intrinsic type.

For the purposes of this feature, we also consider string and object
to be built-in types, in addition to the actual intrinsic types provided
by the compiler.

Covering tricky cases where the receiver is a byref and we do not know whether it is of a value or a reference type.
Those are cases when we do not know statically whether to clone the receiver (to prevent NREs) or pass as byref (for sideeffects propagation into receiver instance).

Due to issues #7584 and #7587 adding `this.`/`Me.` is disabled for
methods and events.

Also add tests for verifying that no diagnostics are generated for static
access or `base`/`MyBase` access.

Get support for squiggles and LB in "AnyCode" workspace

disable entry filter definition for now.

These tests were testing that replacement to var works where type is
apparent. but they also had another rule that said prefer built-in
types. so i update these tests to not use built-in types and replace
them with their framework counterparts. That way we're now clearly
testing if the fix works where type is apparent.

the base type we need to use EntryFilterDefinition is exchange type that needs to be moved to immutable dll.

for more detail see https://github.com/dotnet/roslyn/issues/9096

The user option gets style preference for built-in types but the
implementation checked only for built-in types used _with_ literals on
the right hand side. I guess I had two different choices in mind - for
built in types overall, or where we use literals in the right hand side
and implemented half of both.

Anyway, this clears that up - the option gets the preference for
built-in types and the implementation checks for predefined types (not
literals alone).