Using C++11, we should only need two files I believe.

This was not gaining us much when we were calling clone() on the templated type,
so it basically had to be a Node anyway.

If you care about this, you can force it yourself or use a different back end
build system.

C++17 was not gaining us significant functionality, for how much portability we
lost in using it.

This commit includes the following:

  1. Removal of std::optional. This was not gaining us any clarity.
  2. Remove structured decomposition. This is a C++17 feature.
  3. Better Node hierarchy functionality (rule-of-4.5 etc).
  4. Removal of some overly general structure in Symtab.
  5. Removal of explicit on constructors. Not so useful.
  6. Removal of std::shared_ptr. Causing lots of mess and not helping much.
  7. Removal of unhelpful cases of noexcept.

Not used relevantly yet.

It turns out we can leverage some pretty powerful syntax and type resolution
features from C++17 to reduce the complexity of code generation. It's not
immediately clear to me whether this will result in degraded performance of
final code, but I think it's safer to bet on the C++ compiler's ability to
optimize code over my own. In the short term, this definitely simplifies our
task. I think a reasonable approach is to push forward in C++17 and, once we
have a working first version, consider whether porting to C11 would gain us
anything.

This makes the output a bit more readable. Previous translation unit
consolidation can be regained during compilation with -fwhole-program.

It looks like it may be simpler to emit constants as functions rather than enums
as I had planned. This is fine, but means that we now need to access them via a
function, rather than a symbol.

This was always the intention.

Suck it up, princess.

More seriously, I don't see the value proposition here. If you want nicely
readable code, run the output through ``clang-format`` before you look at it.

Note that this calls out to a generated type function (the writer) for which we
do not yet generate a definition. So far this looks like a pretty reasonable
approach though.

They can now be referenced in e.g. assignment statements.

Note, these are not yet registered in the symbol table so you cannot yet
reference them.

More consistent.

This makes for a cleaner class hierarchy where we catch at compile time when
we're trying to use something as an lvalue that can never actually serve as one.

It didn't seem like this alias abstraction was gaining us anything and it was
becoming a bit of a problem when it needed to sometimes represent a
SimpleTypeExpr and sometimes an aggregate.

There are still some unresolved issues we'll have to tackle here. In particular,
 - lvalues of simple typed variables that are contained in aggregate types
 - rvalues/lvalues of ExprIDs
 - discriminate TypeExprID between a simple and aggregate reference

We may actually want to remove this in future once things stabilise and there
are certain nodes that do not need it. For now though, it seems more flexible to
just make it available to all nodes.