It turns out there's a case inside guards (and possibly other contexts) where
the state reference we have is const and, for this reason, we want any
references to state variables to be const. We achieve this by calling an
overloaded static function that allows us to return a qualified constructed
object.

We now model references to state variables and local quantities using the same
classes. The type of any particular variable is determined at construction time.

Because we constant fold them, they can easily trigger false positive compiler
warnings about being unused.

There is some ambiguity here in some places, so best to be explicit.

My thinking is that we can emit a single type that models both a reference and a
value. Which is in use will depend on the constructor called, which should
always be static. As a bonus, I think this should give us functions/procedures
for free without having to tweak this scheme.

This is necessary to allow referencing state variables at runtime.

All the better to catch you with, my pretty.

This ensures we discover their non-constantness or things like division by zero
at code generation time instead of checker runtime.

Note that there are no accessors for the state generated as yet.

This relates to the previous commit and trying to unify the referents of
ExprIDs. This should pay off in simplification in the long run. Note that this
restores the ability to reference state variables.

It turns out that, in practice, the only thing a symbol can refer to is a
declaration (with some minor wrinkles to deal with Enums). To simplify things,
we can now simply unify ExprIDs as referring to Decls.

This is part of a larger change towards lookups of symbols seeking Decls, rather
than something like a Var. In the short term, this breaks Enums and their lookup
resolution.

Bugs Everywhere is no longer maintained and the only open bugs we had were
actually already dealt with.

It seems we will probably not need this.