More flexible pattern matching

[dhess]

For now, this is just a placeholder issue so that we don't lose track of this feature, but we would obviously like to support more flexible patterns than we currently do. Specifically, we would like to be able to support deeper/nested patterns.

Note that we believe our current pattern matching implementation is sufficiently powerful to represent any program we might want to build. More flexible pattern matching would simply give the student the opportunity to be more concise.

However more flexible we make pattern matching, it will require some sort of overlap & exhaustivity checking.

Refs:

• Live Pattern Matching with Typed Holes

[georgefst]

Note that adding nested patterns will require us to revisit our typedef-editing actions.

For one thing, currently if we edit a type T, we only need to modify expressions where the scrutinee has type T. But instead we'd have to check for any types which contain T as a subexpression.

We'll also need to generalise all of the rules about match expressions in #267, to the case where the edited type appears in a nested position (I've only thought about this briefly, but I don't foresee anything fundamentally different being required).

[dhess]

We now have simple wildcard patterns, but next we would like support for "deep patterns" via some sort of pattern language. Note that this a post-Primer-language 1.0 feature.