Signature Help: Prefer non-obsolete overloads 

* Async-ify a bunch of things

* Failing tests

* Use the field naming style when generating types

Add tooling to CodeStyle layer to generate global configs

Specify publishing location for Microsoft.CodeAnalysis.Collections

 Show generated files live in Solution Explorer

Signed builds are failing because they don't know where to publish this package - https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4308605&view=logs&j=20fcf628-b65c-5865-625a-1cef81cda63b&t=7efdce5b-215a-5afd-980e-58e9cb1ef7e6&l=26

Per @sharwell since this is similar to MS.CA.PooledObjects / MS.CA.Debugging we'll use the same arcade feeds

It's not clear to me if the IAttachedCollectionSource API gives you
any way to know if your collection isn't being needed anymore; for now
this ensures we clean up once the project is removed.

I'm settling on this approach for two reasons:

1. A generator producing no items isn't an unusual case, but might
   indicate to the user something isn't working like they'd expect.
   Being explicit is probably good here.
2. I don't have a better idea. We only compute the contents of the list
   when the node is open, and we stop that background work when the list
   is collapsed again. Unlike say the nodes we show to see the types
   under a source file node (which only involves inspecting a single
   tree), computing whether there even are any generated output files
   is potentially quite expensive. Therefore, we are always showing
   an expansion arrow, no matter what. If we hid the arrow if the user
   tries to expand it and there are no files, then they have no gesture
   to say "I don't care" so we stop doing background work; we'd be
   running generators in the background until at least one file was
   generated, at which point they could collapse it again. This is
   assuming that generators aren't always running for all projects and
   there's an actual difference here, which for now is an assumption I'm
   making.

This updates the Solution Explorer to show the generators underneath
an analyzer node like we do diagnostics today, and under the generator
node we show individual files. I'm doing this as a two-stage hierarchy
for a few reasons:

1. Computing the list of generated files isn't cheap (we need to run
   the generators, after all), so that way you don't see them or pay
   overhead unless you really want to see them. Expanding an analyzer
   to see if it has configurable diagnostics doesn't pay any cost.
2. It's a bit easier to see which generators are generating which files,
   if you have multiple generators in the same assembly. I'm not sure
   if that matters or not in the real world, but if you had two
   generators in the same assembly and they generated two files with the
   same hint path, you have some easy way to differentiate.
3. It kept the code a bit simpler to maintain, although I now realize
   that I could have split the BaseDiagnosticAndGeneratorItemSource into
   two separate IAttachedCollectionSources.

We keep the list updated in the background if it's expanded. We refresh
very slowly (only after five seconds of no activity) after the initial
expansion to avoid unnecessary work; in practice a lot of generators
will produce a fairly stable list of hint names from one run to the
next, so most people won't notice.

You can double click an item to open the dynamic file view.

Merge features/ioperation into master

Add experimentation to "Usings on Paste" 

Merge branch 'issue/import_on_paste_setting' of https://github.com/ryzngard/roslyn into issue/import_on_paste_setting

Address remaining PROTOTYPE comments.

Refresh CodeLens count when showing popup

Share collections

Wait for cancellation before closing streams

Implement ContextVariableArgumentProvider