C#: Use static constructor as enclosing callable for static member initializers.

[michaelnebel]

The query cs/useless-assignment-to-local produces some false positives for static members.
That is, the query incorrectly reports x as being a useless assignment in

public static readonly IEnumerable<int> StaticQueryBackedField =
        from x in new[] { 1, 2, 3 }
        where x > 1
        select x;

The root cause of the problem is that the static member initializers don't have an enclosing callable (which affects the SSA logic and this bubbles up into the results of cs/useless-assignment-to-local query). In this PR we fix the problem by using the static constructor as the enclosing callable for the control flow elements/expressions of static member inititializers. For instance fields, there is a dedicated synthetic "object initializer" method (as there can exist multiple instance constructors). However, there is exactly one static constructor, so we can use that as the enclosing callable.

Notes on DCA.

• Performance appears unaffected.
• Notable changes for several queries. I spot-checked the results and they mostly appear to be good.
  • cs/useless-assignment-to-local. There appears to be two genuine alert removals. I only checked the alert removal in non-generated code and that appears to be a false positive removal (local variable declaration with subsequent use in a static member initialization - similar to the example provided above).
  • cs/dereferenced-value-may-be-null: New alerts, which look good (method calls without null-checks on static members that are assigned the result of a cast).
  • cs/coupled-types: New alerts. The query uses the enclosing callable for finding candidate types of variables accesses. I have no reason to doubt that these are not sound with respect to the query logic.
  • cs/local-not-disposed: New alerts. I checked one, which looks sound. An IDisposable appears to be used as a part of initializing a static field. The query also relies on enclosing callable as a part of its logic.
  • cs/virtual-call-in-constructor. New Alerts. These are false positives, but that is due to a query bug as we shouldn't consider nameof(VirtualMethod) a virtual call - this is perfectly safe in constructors as well. Will open an issue for this.