Related to #45296.

From specification:
If the record is derived from `object`, the record type includes a synthesized readonly property equivalent to a property declared as follows:
```C#
protected Type EqualityContract { get; };
```
The property is `virtual` unless the record type is `sealed`.
The property can be declared explicitly. It is an error if the explicit declaration does not match the expected signature or accessibility, or if the explicit declaration doesn't allow overiding it in a derived type and the record type is not `sealed`.

If the record type is derived from a base record type `Base`, the record type includes a synthesized readonly property equivalent to a property declared as follows:
```C#
protected override Type EqualityContract { get; };
```

The property can be declared explicitly. It is an error if the explicit declaration does not match the expected signature or accessibility, or if the explicit declaration doesn't allow overiding it in a derived type and the record type is not `sealed`. It is an error if either synthesized, or explicitly declared property doesn't override a property with this signature in the record type `Base` (for example, if the property is missing in the `Base`, or sealed, or not virtual, etc.).
The synthesized property returns `typeof(R)` where `R` is the record type.

AnalyzerDriver performance improvements

Update vs-threading analyzers to 16.7.53

Avoid exposing PrimaryWorkspace to LUT/SBD

Features/static lambdas

* Standardize .NET Core / Standard references

This changes us to use standard references for our .NET Core and .NET
Standard unit test compilations.

The exception here is `netstandard1.3` usage which was not altered by this
change

Fixes #45757

RQName cleanup

Fixes #45661
* Add test from contributor at #45742
Fixes #43834

Align addition of a synthesized record.Equals(record? other) in records with the latest design. (#45647)

Related to #45296.

From specification:
includes a synthesized strongly-typed overload of `Equals(R? other)` where `R` is the record type.
The method is `public`, and the method is `virtual` unless the record type is `sealed`.
The method can be declared explicitly. It is an error if the explicit declaration does not match the expected signature or accessibility, or the explicit declaration doesn't allow overriding it in a derived type and the record type is not `sealed`.
```C#
public virtual bool Equals(R? other);
```

Update Roslyn.Services.UnitTests.Utilities to target netcoreapp3.1

Co-authored-by: NCyrusNajmabadi <cyrus.najmabadi@gmail.com>

Nothing is using UnresolvedRQNode directly, so we can just flatten the
type hierarchy a bit.

This annotation revealed a number of places where if some part of RQName
generation failed, we'd end up creating RQNode objects with null fields;
trying to convert that to the text would end up crashing. This adds
proper error handling when issues were discovered by analysis.

Make netcoreapp3.1 the preferred target framework

Log optimization data branch name during official build

Update optprof pipeline for 16.7

Targeting Remote.ServiceHub project to .Net Core

No-op SymbolSearchUpdateEngine on non-Windows OS

This change standardizes the reference assemblies we use for compilation in our unit test to be the actual .NET Framework reference assemblies. 

Prior to this change they were a mix of reference and implementation assemblies from non-RTM versions of the .NET Framework. In order to map the existing assemblies to their respective target framework version I worked with the servicing team and we mapped them to the closest possible TFM based on their file versions. The bulk of the change is essentially mechanically moving from names like `mscorlib.v4_30319_17929` to `Net451.mscorlib`.

Unfortunately in several cases the non-RTM assemblies didn't cleanly map to a RTM TFM. This was particularly problematic when migrating the `v4_30319` references as this is a mix of a `net40` and `net451` versions. This caused issues in our code base because these references were freely mixed with actual `net40` and `net451` references in the code base. Most of the time this went unnoticed because the test didn't expose the gaps in the APIs. In a lot of cases though, particularly when mixing a version of `System.Core` that did or didn't have `ExtensionsAttribute`, this required some manual inspection on my part and a fix. In pretty much every case this was a straight forward fix but it did mean the change was less mechanical than I would have preferred.

To make this change easier to review I've broken it up into three commits:

1. The actual changes to `Roslyn.Test.Utilities` that move us to the new references.
1. The changes to our test code which required more than a simple straight forward reference update or explicitly involved retargetting code. These are changes I think deserve stronger scrutiny than the more mechanical aspects of this PR.
1. The mechanical changes to move from the old references to the new ones. This is the bulk of the change but is for the most part renames. 

The benefits of this change are the following:

1. Have our test more closely mirror customer scenarios by using official reference assemblies.
1. Improve the readability of the tests by referring to assemblies by their target framework, which is familiar to most developers, instead of their file version, which is familiar to servicing team only.
1. Reduces the build output size of Roslyn by **~5GB**

The internal PR is here https://github.com/dotnet/roslyn-internal/pull/1954

Note: I will be making more changes in this area in future PRs. But I wanted to keep the mechanical portion of this change into its own PR. Further PRs will be smaller but less mechanical. 

Ensure that we de-dupe the configuration/suppression code actions