.. the new use var codestyle options.

.. 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).

Implement a fix all provider for `Prefer Implicit / Explicit type` code
style. We simply use the default batchfixer here to fix all nodes which
don't comply with the user settings.

Notes:

1. we do not differentiate between Notification styles when fixing all
non-compliant nodes. i.e., say 2 different locations violate the user
preference, but one has notification level 'warn', while the other has
notification level 'info', invoking fix-all here will fix both the
nodes.

In other words, fix-all doesn't differentiate between two nodes that
have different notification levels or severity levels.

2. this is a given, but still noting it down. we do differentiate
between nodes with different style preferences. For e.g: say the user
prefers explicit type for built-in types but implicit type everywhere
else, the batch fixer would fix only nodes that do not comply with the
preferences.

3. the current implementation fixes all occurrences of the same kind of
violation - using explicit type when implicit is preferred or
vice-versa, however, it does not fix all violations between kinds
(implicit -> explicit, explicit -> implicit). This is because my current
implementation has a different diagnostic for each kind of violation.
Having a single diagnostic and fixer would have been better for this.
I'll add this to my todo list.

Merge master into future

Feature: Suggest implicit or explicit typing code styles.

.. symbol than Parsing the display string of the symbol.

being a denylist to being an acceptlist.

minor naming changes and moving some code around.

Most fixes are about code style.

Major changes are in:
1. the algorithm to determine if type is apparent in creation or conversion methods.
2. option serialization/deserialization.