Fixes #8297 by checking to see if the cascaded constructor (or similar) is a keyword. This is the same check
that's performed when deciding whether to allow rename to be invoked on a constructor (or similar). This should
only impact VB

Fixes #8139

We were previously asserting that renaming a private member meant that the rename operation would occur entirely in that member's declaring project, but rename affect other projects if the private member is an explicit implementation of a public interface member.

No functional change here.

This is all the tests that we've seen fail as a part of investigating
issue #9308.

Closes #9079 #9080

Manually inspected the WorkItem values and added the appropriate URL.

These tests were all using WpfFact, but not actually doing anything
that required either WPF or an STA thread. We plan to enable
parallelization of Facts (but not WpfFacts), and this ensures we can
parallelize as many tests as possible.

Fixes #1195 "Renaming a member to a name used within a nameof is a
conflict"

When a nameof expression is involved in a rename, conflicts are only
introduced if the nameof previously referenced a non-empty set of
symbols and the post-rename set of referenced symbols contains none of
the previously referenced symbols. This allows overloads to join or exit
the set of references without conflicts, but a conflict is still offered
if the nameof switches from referencing a method to referencing a local
(or similar).

Fixes #1729

The C# implementation of IRenameRewriterLanguageService.LocalVariableConflict was returning conflicts any time a related invocation expression bound to a local/parameter, but this condition is not indicative of a conflict when the local/parameter is of a delegate type. This change prevents reporting this particular kind of conflict on references to locals & parameters of a delegate type.

Fixes #1193

During expansion, directly accessed members need to be qualified with
"this." or "TypeName.". Prior to this change, we always qualified
instance members with "this." and static members with "TypeName.", but
this technique fails in nameof contexts where an instance member can be
referenced from a static method, resulting in an improper "this."
qualification. We can only legally use "this." when both the member
being accessed and the context from which we are accessing it are
non-static. However, this change updates the expanders to always use
"TypeName." qualification in nameof contexts regardless of the
staticness of either member because it is always legal and feels more
natural in nameof expressions (where no actual value is being accessed).

The expander can operate on a specific set of known nodes, so when
rename finds a conflict in a particular node, it uses the span of a
parent that the expander knows how to handle. For normal
ArgumentSyntaxes, this is covered by being within a StatementSyntax.
However, nameof within an attribute constructor isn't in a statement, so
rename needs to expand to the span of the attribute.

This change adds support for renaming methods that are referenced in nameof expressions during Inline Rename, Rename Tracking, and RenameSymbolAsync. For all of these features, there are three primary cases:

- Rename invoked from a method declaration with no overloads: Any nameof expressions that reference the method are unambiguous and are therefore updated to the new name.
- Rename invoked from a method declaration with overloads: In this case, any references in nameof expressions are renamed only if the RenameOverloads option is set to true (e.g. when the user checks the "Rename overloads" checkbox in Inline Rename).
- Rename invoked from a reference in a nameof expression: We always rename all overloads by automatically setting the RenameOverloads option to true and disabling Inline Rename's "Rename overloads" checkbox.