[globalisel] Re-factor ISel matchers into a hierarchy. NFC

Summary:
This should make it possible to easily add everything needed to import all
the existing SelectionDAG rules. It should also serve the likely
kinds of GlobalISel rules (some of which are not currently representable
in SelectionDAG) once we've nailed down the tablegen definition for that.

The hierarchy is as follows:
  MatcherRule - A matching rule. Currently used to emit C++ ISel code but will
  |             also be used to emit test cases and tablegen definitions in the
  |             near future.
  |- Instruction(s) - Represents the instruction to be matched.
     |- Instruction Predicate(s) - Test the opcode, arithmetic flags, etc. of an
     |                             instruction.
     \- Operand(s) - Represents a particular operand of the instruction. In the
        |            future, there may be subclasses to test the same predicates
        |            on multiple operands (including for variadic instructions).
        \ Operand Predicate(s) - Test the type, register bank, etc. of an operand.
                                 This is where the ComplexPattern equivalent
                                 will be represented. It's also
                                 nested-instruction matching will live as a
                                 predicate that follows the DefUse chain to the
                                 Def and tests a MatcherRule from that position.

Support for multiple instruction matchers in a rule has been retained from
the existing code but has been adjusted to assert when it is used.
Previously it would silently drop all but the first instruction matcher.

The tablegen-erated file is not functionally changed but has more
parentheses and no longer attempts to format the if-statements since
keeping track of the indentation is tricky in the presence of the matcher
hierarchy. It would be nice to have CMakes tablegen() run the output
through clang-format (when available) so we don't have to complicate
TableGen with pretty-printing.

It's also worth mentioning that this hierarchy will also be able to emit
TableGen definitions and test cases in the near future. This is the reason
for favouring explicit emit*() calls rather than the << operator.

Reviewers: aditya_nandakumar, rovka, t.p.northover, qcolombet, ab

Reviewed By: ab

Subscribers: igorb, dberris, kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D28942

llvm-svn: 293172