Add compiler-generated code dataflow analysis (#2842)

This treats fields of display classes and state machines as hoisted
locals. We track all assignments to hoisted locals within a method
group (the set of compiler-generated code reachable from a given user
method). The analysis is technically flow-insensitive, because it
assumes that any assignment to a hoisted local can reach any read of
the same local. This will produce extra warnings in some cases, but it
prevents holes:

- State will "flow" out of nested functions. That is, writes (to
  hoisted locals) within nested functions will reach reads in the
  enclosing user method
- Lambdas are analyzed at the point of delegate conversion, but with
  all possible states of captured variables. So effectively, writes
  after the lambda declaration will reach reads within the lambda.

Previously, hoisted locals were treated as unannotated, so they would
produce dataflow warnings if they reached an annotated location. Now
that we analyze hoisted locals, cases where the value satisfies
requirements at the point of consumption won't warn. This means that
accessing these fields (representing hoisted locals) via reflection is
problematic, since it could mutate the values of these fields and
invalidate the correctness analysis. For this reason we now warn on
reflection access to compiler-generated fields.

To prevent noise, we only warn for reflection access to
compiler-generated fields that represent types which may be
annotated - so Type, string, etc. - but not int. This is technically a
hole because ints also participate in dataflow analysis but we are
choosing this tradeoff to avoid excess warnings for integers.

This also includes some cleanup of the type hierarchy logic and
extra comments to make it more clear how this interacts with
warnings for reflection access to compiler-generated code.

0 files changed, 0 insertions, 0 deletions