Record pattern and side effects

[Izz Rainy]

While it's pretty easy to say that record deconstruction should never have
side effects (or generally be stateful beyond the record), would you also
extend that to all custom patterns? It seems to me that stateful, effectful
patterns could be useful if explicit enough.

Given some IntelliJ-like AST system, we could have code like

```
AstElementReference elem = ...;
switch(elem){
  case DirectRef(var ast) -> ...
  case AstCache.cacheOf(var ast) -> ...
  case Stubs.stubOf(var ast) -> ...
  case FileIndex.refToUnparsed(var ast) -> ...
  default -> throw ...
}
```
where accessing (or creating) an underlying AST element might be stateful,
and where proper polymorphism may not be appropriate (e.g. I don't control
these types, or what I'm doing with them is not meaningful for all
subtypes, or...).

An equivalent if/else chain might look like

```
if(elem instanceof DirectReference(var ast)){
    ...
}else if(elem.isCache()){
    var ast = AstCache.get(elem.key());
    ...
}else if(elem.isStub()){
    var ast = Stubs.createMirror(elem.key());
    ...
}else if(elem.isFileRef()){
    var ast = FileIndex.parse(elem.key());
    ...
}
```
or something. An enum might be more appropriate for representing types, but
that's irrelevant to what the patterns are doing; they're moving out the
"obvious" step of data extraction into the conditional, making it clearer
what the "actual" logic is, similar to type patterns but more domain
specific.

In this example, it's clear that side effects are only appropriate on a
successful match. Stateful failures *may* be required if a stateful pattern
is nested within another pattern, or guarded by a when clause, though;

```
switch(elem){
  case Stubs.stubOf(AstClass.classAst(var clss))
    -> ...
  case Stubs.stubOf(var ast)
  when ast.isPhysical()
    -> ...
  default
    -> throw new IllegalArgumentException();
}
```

Factoring out a common head would be the "correct"/more efficient behaviour
in this case, but as pointed out already, it's not possible to do that for
all duplicate occurrences of a pattern.

The behaviour I would expect here is essentially "mimicking an equivalent
if/else chain", ensuring that I can always refactor between a switch and
ifs without new behaviour, always evaluating top-to-bottom left-to-right.
But that's also bad for the majority of patterns that are expected to be
pure.

I'd suggest providing an annotation for impure patterns, then, which
prevents the compiler from optimizing the switch in "unexpected" ways, and
allows warning when an impure pattern is repeated (in the compiler or by an
IDE), alongside making it clearly documented and explicit.

If the annotation is not present in a switch, the compiler gets to reorder
and factor out any part it wants.

For the purposes of JDK 19? record patterns, where the dtor cannot be
explicitly written out, the annotation would have to be applied to the
whole type, or a particular accessor.