New pattern matching doc

[Brian Goetz]

> You should also talk about the last tier of the onion, the translation strategy, because i may be wrong but ii think it will ripple to the two other parts
> (syntax and semantics).

Of course we have to talk about that, eventually.  But there's a fine 
line between "pick a model that can be efficiently translated" and "let 
the translation-tail wag the model-dog."  I would like to focus on the 
object model first, and language model second, because a perfect 
translation cannot save a bad design, but a good design can tolerate an 
imperfect translation.  (And it is not the case that we haven't been 
thinking about translation as we go.)

> At definition site, a pattern method is obviously a method and as Brian as proposed earlier, bindings can be represented by a synthetic record as return type, so something like

A synthetic record is obviously a good candidate, but not the only one.  
For patterns with only one binding, no record "box" is needed; for some 
patterns, having a synthetic "box" is just wasted motion (e.g., when the 
object can be act as its own witness to its bindings.)  So we should 
keep synthetic records as possibilities, but we should not jump to this 
as The Answer.

There's an older doc at:
https://github.com/openjdk/amber-docs/blob/master/site/design-notes/pattern-match-translation.md

that outlines an alternative strategy, which is potentially richer and 
more efficient, and which was discussed at the JVMLS talk that year.  
There, we have the method return not the matched values, but a Pattern 
(which is a constant!), where a Pattern is a bundle of method handles.  
The first method handle is a function from Target to Carrier (where 
Carrier is a runtime implementation detail), where a null carrier means 
"no match", and the other method handles are functions from Carrier to 
Binding_i.  These are all amenable to loading and composing via condy.  
In this world, no classfile has to utter the name of the carrier class, 
you just get it from one MH and feed it back to another.

But, I really would like to not get ahead of ourselves, so I would 
rather not dive into this at the cost of distracting from the object 
model decision.  (Unless we're done with the object model decision?)

> Given that we want to support overloading, the record corresponding to the bindings as to be present as return type, so overloads are pattern methods with the same name, may be the same parameters but a different return type.

I have proposed using the SF encoding of the erasure of the binding 
descriptor as part of the name.  But again, the important thing right 
now is that there is a path, not nailing down what that path is.

>    if (carrier.match) {
>      var i = carrier.i;
>      ...
>    }

Or:
     var i = iComponentMH.invokeExact(carrier)

But, please let's table this until we are finished with the object model 
discussion.