Correctly localize the "Failure" and "Warning" strings

Ensure that VB XML doc comment completion returns correct tag names

Rename ContinueAsync to RunFromAsync and make it public

Ensure DeclarationTreeBuilder.GetModifiers doesn't throw on unexpected tokens that have errors.

Handle default parameter values for event accessors in CreateBinderForNodeAndUsage.

Prevent NaN from slipping into .Measure calls.

Fixes #8514

Normalize paths when generating pipe names

Harden determinism job

Fix Code Model race for real this time

Misc renames and minor cleanup

Add CompilationOutputFiles test helper.

I thought I'd fixed this subtle race with PR #8607. After all, the check-in tests were passing and it passed locally on my machine.
However, it was still failing consistently on the build server. Finally, I noticed that the only test passes that were failing were
on x86 *Release* (insert sound of forehead being smacked). After compiling Release, I could reproduce the problem locally.

It turns out that this was a race with GC. In a previous fix, when adding an element to FileCodeModel's element cache, we would first
check to see if the element was already in the cache. If it was in the cache, we'd remove it before adding it. However, the test to
see if the element was in the cache called `CleanableWeakComHandleTable.TryGetValue(TKey key, out TValue value)`, which would only return
true if `key` was in the cache and `value` was not set to null. In essence, it's defined like so:

```C#
public bool TryGetValue(TKey key, out TValue value)
{
    this.AssertIsForeground();

    WeakComHandle<TValue, TValue> handle;
    if (_table.TryGetValue(key, out handle))
    {
        value = handle.ComAggregateObject;
        return value != null;
    }

    value = null;
    return false;
}
```

However, when running in Release, the GC can run a bit more aggresively and `handle.ComAggregatedObject` (a weak reference) could easily be null.

The fix is to add a simpler `CleanableWeakComHandleTable.ContainsKey(TKey key)` and use that instead.

```C#
public bool ContainsKey(TKey key)
{
    this.AssertIsForeground();

    return _table.ContainsKey(key);
}
```

Enable Glyph's on code actions.

Don't call GetGenericsArguments unless IsGeneric is true

It turns out APIs are very inconsistent in whether they leave a trailing
directory separator on path names. This caused the client and server
code to generate different pipe names for the same file location. Hence
VbcsCompiler -shutdown was failing because it used the wrong pipe name.
Fix this by normalizing path names.

This hardens the determinism job:
- Properly terminates build processes on exit
- Creates a zip file of all information needed for investigation on
failure

Test projects automatically inherit app.config

Fix race in Code Model cache

Fixes #8400.

Add "*" on enter pressed within comment blocks

Fixes #8401.

Update to SRM 1.2.0-rc3-23811

Document "Better Betterness" for C# 6 and the compat fix

This addresses a race condition introduced in our per-FileCodeModel cache of code elements by PR #8424. In that change, we attempted to
handle the situation where a code model element is about to be inserted in the cache with the same "node key" is an element that is
already in the cache. This can happen in normal operation if a Code Model consumer were to programmatically add a variable, delete
the variable's underlying text and immediately add the same variable again. The original fix would conditionally remove the old
element from the cache if its "node key" could not be resolved in the FileCodeModel's current syntax tree. Then it would add the new element
with the same "node key" to the cache. However, this appears to not be deterministic and would sometimes result in a collision.

This PR changes the policy to **unconditionally** remove the old element from the cache if one exists before adding the new element.
Because the purpose of the cache is to return existing elements when accessing various collections (e.g. "Members"), it makes sense
that the latest element would be returned. In addition, because the "node key" referenced by the old element has become valid again, accessing
properties on the old element will continue to work.