private and protected members in mixin classes (#13990)

continued

• Look at tests in Properly handle private and protected properties in intersections #13990
  • We've got a bunch of mixable classes.
  • Each one has a member called p that are all strings.
  • Whenever you mix two things which have no clashes, we "zip" the symbols and everything checks the way it's supposed to check.
  • The minute we have a collision, we synthesize a property and have to decide what the accessibility is.
    • When unrelated private members collide, it should really be considered an error.
    • But we can't report errors when we generate intersections!
    • But at the very least, we can co-mingle the privates.
    • Accessing from the outside will be an error.
    • Can't report an error at mix-time. :(
      • But we can report an error if you derive from a mixed type! So we've got that going for us.
    • What about private/protected/public?
      • Private always poisons the pot as described earlier.
      • Protected/protected continues to be protected (can't be accessed from the outside).
      • Can widen from protected to public.
• Internal changes
  • Symbol flags went up to 31 flags.
    • Bad because that means flags get boxed at runtime.
  • SymbolFlags.Merged was removed.
    • Merged symbols are just transient, can just use SymbolFlags.Transient.
      • Poof.
  • Instantiated and SyntheticProperty
  • Transient symbols are symbols created by the checker.
    • Symbol links need to be kept by the checker.
    • Anything used only by symbol links (and therefore the checker) can get its own flags.
    • Introducing CheckFlags
    • getCheckFlags gets you CheckFlags.