This works, but it makes me slightly nervous that the Var of a quantified
variable is only sustained by shared_ptrs of ExprIDs related to where it is
referenced. I.e. Once we traverse out of parsing the forall expression, the
enclosing scope is closed and the Var is destroyed if it hasn't been referenced.
On the one hand, this seems fine and might even help us later in detecting
useless quantification. On the other hand, the lifetime of this Var object is
quite slippery.

Well that was a rude surprise. VarDecl lookups in the symbol table failed
mysteriously and debugging indicated they had no name. Some digging revealed we
were accidentally shadowing Decl::name.

It is pretty surprising to me that -Wall -Wextra does not enable -Wshadow, which
would have caught this. Unfortunately we can't turn it on right now because it
sprays warnings about the constructors that shadow class members with their
arguments. Sigh. I guess I'll have to refactor this before turning it on.

This expression is used for referring to variables (either parts of the state or
local variables). I'm still not sure this is the natural solution. It feels like
this and ExprID should be a single class, but we'll see how it goes.

Note that you can't currently reference the quantified variables within the
forall expression as explained in the FIXME comment.

This allows us to drop all the destructors and simply let reference counting do
its job. I don't think we should take this approach in the checker because
shared_ptrs aren't free, but the generator is not performance critical. Note
we retain a raw pointer for ExprID::type_of. It's difficult to avoid this
without introducing circular references or memory leaks. I think it's fine for
now.

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