Add FixAll in containing type/member support for code fixes

[mavasani]

Currently, one can apply FixAll operations to Document, Project and Solution scopes. Now, we also support fixing all diagnostics in containing member and type scopes, wherever applicable.

Closes #60029

Screenshot

Note

1. Fix all in ContainingType scope fixes all diagnostics in all the partial definitions across files, not just the type declaration in current file from which the fix is triggered.
2. If the trigger diagnostic span does not have a method level member declaration as it's containing symbol, we do not offer ContainingMember fix all option (for example make class static code fix for CA1822).
3. Similarly, if the trigger diagnostic span does not have a type declaration as it's containing symbol, we do not offer ContainingType fix all option (for example remove unnecessary usings code fix for IDE0005).

Added Tests

1. Unit tests: C# and VB unit tests tests for both FixAllScope.ContainingMember and FixAllScope.ContainingType in following buckets:
   1. Method body level code fix, so that both these fix all scopes are applicable for the code fix.
   2. Type declaration level code fix, so that only ContainingType fix all scope is applicable. We verify that ContainingMember fix all scope is not offered for such a code fix.
   3. File level code fix (remove unnecessary usings), so that neither of these fix all scopes are applicable. We verify that both these fix all scopes are not offered for such a code fix.
   4. FixAll tests for suppressions for both these scopes.
2. Integration tests for both FixAllScope.ContainingMember and FixAllScope.ContainingType.

[jmarolf]

Use a builder?

[mavasani]

So, for 99% cases we expect a single FixAll span entry here. We get multiple FixAll spans within a document only for the case where a single named type has multiple partial definitions defined in the same file, which is almost never the case in real code bases. I don't think we need to optimize for this corner case.

[CyrusNajmabadi]

my general concern is simply that the builder approach is just as easy to write, and works well for the 1 to many case. I agree it's unlikely, but really rthe ImmutableArray.AddRange approach really stands out like a sort thumb as "this is just waiting for an unfortunate case. Note: sam's TemporaryArray is great here. just do:

using var diagnostics = TemporaryArray<Diagnostic>Empty;

As fast for the normal case (<4 items), and no pathlogical dropoff.

[CyrusNajmabadi]

done iwth pass. almost all nits. did see a concern with global statements.

[mavasani]

Thanks @CyrusNajmabadi - feedback addressed