Refinements for sealed types

[Brian Goetz]

> To be clear, infer `final` on A. We were already inferring `sealed` 
> last week; the new thing this week is to infer A's `permits` list as 
> empty (giving A an overall score of implicitly `final`) rather than 
> "any co-declared subtypes of A". Given the code above, it is a 
> compile-time error for any class in any compilation unit to attempt to 
> subclass A.

I don't have a strong opinion on whether "sealed but no permitted 
subtypes" is a habitable space separate from "final", but I'm fine to 
say "that means final" for most purposes.  Not sure what reflection 
should say; is it OK for a type that is clearly sealed in its 
declaration to report back as "not sealed, but final?"  Or does that 
mean it is both sealed _and_ final (an empty PermittedSubtypes 
attribute, plus an ACC_FINAL)?  Similarly, depending on where we land on 
this decision, it affects the binary compatibility consequences (e.g., 
is it binary compatible to go from final to sealed (with or without any 
permitted subtypes)?

> Where this is all headed is that we never infer `sealed` with a 
> non-empty `permits`. As you said, no need for `permits none`. It is 
> good to draw a clear distinction between 
> `sealed`-with-at-least-one-permitted-subtype versus 
> `final`-with-zero-subtypes.

I'm fine with this, modulo above details-to-be-worked-out.