These unit tests will now assert that casing is unchanged by
`FilePathUtilities.GetRelativePath(...)`.

The `FilePathUtilities.GetRelativePath(...)` method is used in various
places in the Workspaces and VS layers to generate a relative path from
a starting directory to a target file or directory. However, it has a
bug where it will generate an incorrect path if you need to go up more
than one level from the starting directory to get to the target.

For example, if the starting directory is `C:\Alpha\Beta\Gamma` and the
target is `C:\Alpha\SomeFile.txt`, the correct relative path would be
`..\..\SomeFile.txt`. Instead, we get `..\..\..\SomeFile.txt` (note the
extra `..`).

This commit fixes the issue and adds unit tests for this method.

Update PublicAPI.txt to reflect recent changes to Scripting APIs.

added build only filter support to error list

Refine hoisted local scopes in async methods

Make APIs related to scripting and interactive internal for RTM

Improve undo stack titles for suggestions applied via light bulb

Use assembly name for analyzer ID

Use the actual assembly name for `AnalyzerFileReference.Id`, instead of
a lowercase version of the file name.

There are places we are currently using `AnalyzerReference.Id` when what
we may want is `AnalyzerReference.DisplayName`. Notably, in the rule set
editor. This means that after my recent change to simply return the
lowercase version of the analyzer assembly's file name, the rule set
editor started showing "microsoft.codeanalysis.analyzers.dll" instead of
"Microsoft.CodeAnalysis.Analyzers".

The "right" solution would probably involve an API to map from an ID
back to an `AnalyzerReference`, and then using the `DisplayName` in the
rule set editor instead of the `Id`. At this stage in the release cycle,
however, I'm going with a simpler solution: make `AnalyzerFileReference`
return the same value for `Id` and `DisplayName`, and get that value by
reading the assembly name from the file itself, like we used to.

Fixes #2781 and #2782.

Fix typos

Fix analyzer type load error reporting, API

Visit InitialValue as rvalue in AbstractFlowPass(Of ).VisitFieldOrPropertyInitializer.

Old: Scopes followed the bound tree, so the outermost scope was within the
try-catch block synthesized in async MovedNext methods.

New: If the entire try block would be a hoisted local scope, we remove the
marker node (BoundStateMachineScope) and insert a new one around the
entire method body.

Upshot: hoisted locals are still in scope when stopped on method closing
braces.

Exception)...

Fix typos

Change pipe checksum to SHA256

Implement Dynamic View expansion...

(fixes #1743)

Use the actual `AssemblyIdentity` for `AnalyzerFileReference.Id`, instead of
a lowercase version of the file name. Also use `AssemblyIdentity.Name` as the
`DisplayName`.

If we can't read the file for whatever reason, fall back to strings
generated from the file path.

Fixes #2781 and #2782.

Fix nulls in AnalyzerDependencyChecker.

Currently we use a `Task.FromResult(null)` as a sentinel task before a
real dependency check has been queued up. This works fine until we try
to access the results of this task, and things blow up.

Instead, we should create an AnalyzerDependecyResults.Empty singleton,
and create a task from that.

Also, this change catches all exceptions coming out of
`AnalyzerDependencyChecker`, to avoid bringing down VS.

Disable Deterministic PDB GUID generation for RTM

Fixes #2896.

Only return a fix if the assembly identity matches the diagnostic mes…

Don't leak Workspace objects from AnalyzerAndOptions

Add tests for #976. The actual fix for this was in the compiler #2540.

Introduce local on interpolated string expressions should not generate a
constant, but a variable.

Add tests for #976. The actual fix for this was in the compiler #2540.

Introduce local on interpolated string expressions should not generate a
constant, but a variable.

Guard visitors against stack overflow exceptions

Currently we use a `Task.FromResult(null)` as a sentinel task before a
real dependency check has been queued up. This works fine until we try
to access the results of this task, and things blow up.

Instead, we should create an AnalyzerDependecyResults.Empty singleton,
and create a task from that.

Also, this change catches all exceptions coming out of
`AnalyzerDependencyChecker`, to avoid bringing down VS.

Handle BoundSequence as an assignment target in CodeGenerator.EmitAssignmentExpression.