Add an extension point to allow services to light up on string-literals (classification only for now)

From the #23984 PR:

The first subsystem is called the VirtualCharService deals with the following issue. To the final .net regex, the following snippets of code appear completely identical to it:

"\\1"       // In a normal string, we have to escape the \
@"\1"       // But not in a verbatim string
"\\\u0031"  // The '1' could be escaped
"\\u005c1"  // Even the backslash *itself* may be escaped

These are all ways of writing the \1 regex.

In other words, C# allows a wide variety of input strings to all compile down to the same final 'value' (or 'ValueText') that the regex engine will finally see. This is a major issue as it means that any data reported by the regex engine must be accurate with respect to the text as the user wrote it. For example, in all of the equivalent cases above, there is the same error "Reference to undefined group number 1". However, for each form the user wrote, it's necessary to understand what the right value is to highlight as the problem. i.e.

https://user-images.githubusercontent.com/4564579/34459671-5bb785b2-edab-11e7-8413-79c331ef373f.png

and

https://user-images.githubusercontent.com/4564579/34459672-6deb88dc-edab-11e7-8236-7ba7cd331247.png

So, the purpose of the VirtualCharService is to translate all of the above pieces of user code to the same final set of characters the regex engine will see (specifically \ and 1) while also maintaining the knowledge of where those characters came from (for example, that 1 came from \u0031 in the last example). In essence, the VirtualCharService is able to produce the ValueText for any string literal, while having a mapping back from each character in the ValueText back to the original source span of the document that formed this.

With the VirtualCharService user code can be translated into a common format that then can be processed uniformly. This means that the part of the system that actually tries to understand the regex does not need to know about the differences between @"" and "" strings, or the differences between C# and VB. It also means that it can be used by any roslyn language (for example, F#) if that is so desired.

Add check for symbol.IsOverride when renaming a symbol

These can be very confusing, since other methods on Contract actually
throw exceptions. Since we have endless amounts of code directly calling
Debug.Assert, let's just use it everywhere.

* Precedence: explicit selection -> provider preference -> last selection -> first/default value.
* Remove logic to bail out on retrigger

* Add AB tests for code cleanup
revert the text change of Code_cleanup_is_not_configured, as the new text is not translated
Only SettingIsAlreadyUpdatedByExperiment to ture for Group B; always show gold bar if user setting is changed in AB test

* remove random last token from engine.

* put the support back to what it used to, but in different way.

* PR feedback

* added comments on the typing rule.

* PR feedbacks

The icacls command is failing on Helix hence disabling these tests there
for now

Related to #28836

If we are doing a rename from a C#/VB symbol, and an F# project depends
on that project, we might end up walking into non-C#/VB projects and
we will crash. This prevents the crash.

There were two ways I could fix this bug: one would be to update
GetDocumentsAffectedByRename to exclude them up front. The other option
is to deal with those at the call sites when we fail to find a service.
I'm electing to do the later as that allows light-up by the appropriate
language services if they wanted to do that down the road.

AddNonSubmissionDependentProjectsAsync is designed to return projects
that depend on a given symbol. It indirectly calls HasReferenceTo
which in the metadata paths will only return projects that have
Compilation support. Thus, it seems safe to exclude the projects
entirely.

Fixes dotnet/roslyn#25655.

This seems to be a popular call among analyzers, especially XUnit. It's a
reasonable way to acquire a well-known analyzer type, but analyzers often
don't save the resulting symbol. This causes significant CPU work to be done
repeatedly as XUnit looks for the same symbol over and over, passing in the
same type name each time.

A very small, simple cache seems to solve the problem without requiring any
changes on the XUnit side.

Also removes stated support for Dev14, which I'm guessing hasn't
actually worked for quite some time.

* make AbstractObjectBrowserLibraryManager constructor lazier

* PR comments

* readonly and use expression body

Looks like RyuJIT change causes our leak detection tests to fail.
Disabling until we find a better pattern to use there.

https://github.com/dotnet/roslyn/issues/28639

Use IHierarchyItemToProjectIdMap service to compare project hierarchies.
Fixes #27002