Re-enable mono CI build

Disable Mono CI build

Ensure we refresh the project output path when the obj path changes

when it happens we will show the info bar and proceed. this is not error recovery but not forcing users to restart VS right away by crashing VS. now user will have time to do what they want and then restart VS

Work around bug in NamedPipeClientStream.ConnectAsync

We don't need to await the call to `ConnectAsync` in the async lambda passed to `Task.Run`. Instead we can just have a lambda that returns the same `Task` returned by `ConnectAsync` and `Task.Run` will do the right thing.

LOC CHECKIN | dotnet/roslyn dev16.0-preview3 | 20190131 2

LOC CHECKIN | dotnet/roslyn dev16.0-preview3 | 20190131

Bring EditorFeaturesResources.*.xlf files in line with the current state of EditorFeaturesResources.resx.

Localize regex tests

This is a reworked version of #32395 targeting the dev16.0-preview3 branch.

This is a reworked version of #32616 targeting the dev16.0-preview3 branch.

`NamedPipeClientStream.ConnectAsync` attempts to be asynchronous by
moving the expensive work (actually connecting to the named pipe) off to
a background thread via `Task.Factory.StartNew(Action,
CancellationToken)`. However, this is the wrong overload to call, and in
some situations is guaranteed to _not_ schedule the new `Task` to a
background thread.

This overload will, by default, use whatever `TaskScheduler` is
associated with the "current" `Task`, if any, and only schedule the work
to at threadpool thread if there is no current `Task` or if that `Task`
is already associated with the threadpool `TaskScheduler`. If, on the
other hand, you're on the UI thread of a GUI application (like Visual
Studio) the new `Task` will also end up scheduled to the UI
thread--exactly the outcome we were trying to avoid.

Once this happens you can easily end up in a situation where a
subsequent blocking call (e.g. `Task.Wait(...)`) blocks the UI thread
while effectively waiting for that `Task` to complete... which it can't
do because the UI thread is blocked! Now you've got a single-threaded
deadlock and your UI hangs.

To work around this issue, here we first force ourselves to a
threadpool thread via `Task.Run` and _then_ call `ConnectAsync`. Thus
the `Task` created by `Task.Factory.StartNew` will also end up on a
threadpool thread.

Revert "Delete VisualStudioMetadataReference, which was now an empty type"

This reverts commit 73f1152e. Right now
F# is still implicitly mentioning this type. This has been fixed in
https://github.com/Microsoft/visualfsharp/pull/6153 but until we can
get that rolled out we'll roll back the name change.

For legacy projects, we would update our bin path whenever the obj
path was updated as a heuristic. We lost that as a part of my rewrite
as a simple oversight; this restores that back.

Fixes https://github.com/dotnet/roslyn/issues/32711

Merge pull request #32813 from jasonmalinowski/fix-metadata-references-not-always-having-file-watchers

Fix bug where references didn't always have a file watcher

Hardcode the optprof drop to the last known good build

Add 16.0-preview3 branches to publish and azure pipelines

Allow locals, parameters, range variables inside a lambda to shadow names outside the lambda

Fixes #32290 
Fixes #32169 
Fixes #32141 
Fixes #32025 

Remove additive classifications when generating ClassifiedText from ClassifiedSpans