This isn't immediately useful as we don't have support for defining array and
record types yet.

This makes more sense when the name of a start state can contain arbitrary
characters that won't be acceptable as part of a symbol (e.g. space).

As this operator is not actually ever considered to be part of an expression,
its associativity and precedence are irrelevant.

This approach is much more general and cleaner (no temporarily malformed
ExprIDs, no forced move reference, ...). This also paves the way for reusing
this for vardecls.

This is the first time I have had cause to use structured bindings and I have to
say, very nice! These really make me feel like I'm writing Python :)

More indicative of how ExprID doesn't own it.

This avoids breaking some implicit invariants of the symbol table temporarily.

This neatly cuts the enum problem by allowing us to associate an enum member
(now ExprID) with the type representing the enum itself.

The implementation of these departs somewhat from CMurphi. Where CMurphi
implements each member of each enum as a separate value (i.e. enum members in
distinct enums will still have different numerical representations), we simply
implement enums as C would. We'll need to do a little more work to prevent
accidental comparison of distinct enum values, but this representation should
allow us to more efficiently encode enum values in the state. This only matters
for input models that contain large enum types, but empirically it seems like
this is much more common than one might think. E.g. see [0].

The EnumValue class and related symbol table declaration implemented in this
commit is a bit awkward. It would be nice to implement this in a cleaner way,
but I couldn't immediately think of a better alternative.

  [0]: https://bitbucket.org/jderick/preach/commits/e7cecfc142253799bdf5d5cc5ed60015ec5cd0a8

Surprisingly this is not enabled by -Wextra.

This better enables library users to catch errors and recover.