[pattern-switch] Exhaustiveness

[Brian Goetz]

> I'm still thinking it's worthwhile to change the behavior of enum switches to throw the same thing as sealed class switches.

I don't necessarily think this is terrible, but see inline.

>
> - ICCE is arguably just wrong. It's not an incompatible change to add an enum constant to an enum declaration.

Kevin made a compelling argument when we did this that ICCE is actually 
right.  The notion is that ICCE is what users are most likely to 
associate with "broken classpath"; that the classes on the class path 
have been inconsistently compiled.  ICCEs go away on recompilation.

This does, of course, hinge on the meaning of incompatible.  Adding an 
enum constant is not binary-incompatible; all the call sites continue to 
link.  But "I've never seen this value before", because the value wasn't 
present at compilation time, is not an unreasonable interpretation.

> - The inconsistency is a risk—somebody thinks they're catching the exception, then they discover, oops, enum switches throw a different exception type for historical reasons.

Yeah, don't care much about this.  No one catches these anyway.

> Of course, behavioral changes are a risk, too, but I think getting it in early, before there's been much time for adoption of switch expressions and evolution of enums, minimizes that risk. (We could even make the change in 16 as a spec bug fix.)

I don't necessarily disagree, and it would be consistent to throw 
UnexpectedFrogException for all non-null remainders, but the status quo 
does not seem wrong to me.