.. Prefer Intrinsic Type codestyle.

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.

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

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.

... with notification levels and also test notification levels.

These are additive minor changes to code naming, styling, documentation,
tests and such. No major functional changes.

We now detect a conversion, if any, do not suggest use var if it changes semantics, as it would for some implicit conversions.
We also recognize type conversion patterns for IsTypeApparent(). For e.g., we recognize static helpers like `int.Parse`, `Convert.ToString()` and instance method `IConvertible.ToChar` etc.

Changed the UI from combinations of radio buttons and check boxes to use
just checkboxes. Also changed how the partitions of `use var` space was
logically represented. We now present 3 options - use var on intrinsic
types, use var where apparent, use var in rest of the places. If all 3
are checked, we universally use var everywhere. If only one or a
combination less than 3 are selected, we use var only in those places.
An unchecked option means, user prefers explicit typing for that
scenario.

Not yet implemented : enforcement levels of the fix, fancy previews that
show results for a combination of choices, integrating the options into
code generation service.

Refactor UseImplicitTyping and UseExplicitTyping Analyzers to use an
abstract base class and share common functionalities. Also wire up
options into unit tests.

Add an analyzer and fixer for using explicit type over var for C#. Plus,
unit tests.

shelving, edit this commit later.