Initial draft of DSL semantics complete.

This latest refactor adds "extractor macros" in place of the
very-confusing-even-to-the-DSL-author reverse-rules-as-extractors
concept. It was beautifully symmetric but also just too mind-bending to
be practical.

It also adds argument polarity to external extractors. This is inspired
by Prolog's similar notion (see e.g. the "+x" vs. "-x" argument notation
in library documentation) where the unification-based semantics allow
for bidirectional flow through arguments. We don't want polymorphism
or dynamism w.r.t. directions/polarities here; the polarities are
static; but it is useful to be able to feed values *into* an extractor
(aside from the one value being extracted). Semantically this still
correlates to a term-rewriting/value-equivalence world since we can
still translate all of this to a list of equality constraints.

To make that work, this change also adds expressions into patterns,
specifically only for extractor "input" args. This required quite a bit
of internal refactoring but is only a small addition to the language
semantics.

I plan to build out the little instruction-selector sketch further but
the one that is here (in `test3.isle`) is starting to get interesting
already with the current DSL semantics.

cranelift/isle/TODO

@@ -1,5 +1,8 @@
-- inputs to external extractors? "polarity" of args?
-- "extractor macros" rather than full rule reversal? (rule ...) and (pattern ...)?
+- Optimizations
+  - Infallible patterns; optimize away control flow when possible.
+  - Don't do the closure-wrapping thing for expressions inside of patterns.
+
 - Document semantics carefully, especially wrt extractors.
+
 - Build out an initial set of bindings for Cranelift LowerCtx with extractors
   for instruction info.