1. Make the error list build and live diagnostic de-duping cancellable: This ensures that repeated builds have fast error list refresh - currently, error list refresh for later builds will wait for all de-duping to complete for prior builds, just to throw away the computed results and re-refresh the error list.
2. Link error list refresh operations to workspace's disposal token
3. Eagerly initialize the saved project diagnostics from persistent storage after solution load to improve the error list refresh perf for the first build

bugfix/msbuildworkspace duplicate analyzer references

* Remove langversion restriction for source generators.

Fixes #47614
See also https://github.com/dotnet/csharplang/commit/2661a4b3950d2ec5c557b025af13e52ba200fd05

Bye for now!

Error list improvements

* Use a distinct diagnostic ID when an exhaustiveness report uses an unnamed enum value.
Fixes #47066

[master] Update dependencies from dotnet/arcade

Related to #47357.

Exclude empty item from completion list

Disable flaky optprof test

This test is hanging on test runs.

Tracking issue #47720

Show events completion inside NameOf

Keep track of the trigger location for async completion

always nuget restore in graph mode

* Classify function pointers correctly

* Use a stable sort for classifications

Add change signature support for target-typed new

Fix lambda completion inside `new()` arguments

only specify minimum heights and widths

Add test to validate non-repro issue.

This is a mitigation for the threading issue discussed in https://github.com/dotnet/roslyn/issues/35818. When building VS, there is a flaky threading issue where an interpolation with multiple parts can end up with different nodes on different threads, causing an optimization in `SetParentOperation(ImmutableArray)` to be invalid. This makes the optimization much narrower, ensuring that it is actually valid for this case.

The specific scenario here is an interplotated string with multiple parts. The steps are:
1. 2 threads attempt to get the children of an interpolated string operation at the same time.
2. Thread 1 gets the child for the first part of the string and caches it.
3. Thread 2 gets the child for the first part of the string and gets that same cached element.
4. Both threads attempt to get child 2. Neither hits the cache, so they get different nodes.
5. Both threads construct the array of interpolated string parts.
6. Thread 1 sets the parent of the interpolated string parts to be itself.
7. Thread 2 attempts to set the parent of the interpolated string parts to be itself. This returns early, because part 1 already has a parent, leaving part 2 with an unset parent.
8. Later, thread 2 asks for the parent of part 2. It is unset, violating the invariants, and we infinite loop.

As an additional mitigation step, we also ensure that the process of constructing an interpolated string's inserts does not hit the cache.  Since we never ask for an operation within a single expression, this will prevent 2 threads from seeing the same first element and differing subsequent elements.

Fix convert-to-switch handling of comments at the end of blocks