TODO

* Split off LillyConfiguration with static settings from LillyConnection
   - LillyConnection points to LillyConfiguration
   - applications can still have multiple LillyConfiguration defined
   - many LillyConnection often share a single, static LillyConfiguration
   - applications will often define LillyConnection as static const data

* Consider unpacking SEQUENCE OF / SET OF
   - we have region memory, so let's use it
   - the data will always be needed anyway
   - generic handling: opcode table entry can list <index,subparse>

* Advance the testing framework
   - check not only the exit code, but also the generated output
   - see test/CMatch.c which starts off this idea
   - wrap it in add_test() around lillydump.test and lillypass.test

* Consider regex-checking attributes with constraining syntax
   - Ragel would be interesting to use, but we don't need to intersperse code
   - libprce is probably more compact; it is already present in Nginx
   - Would be friendly as a syntax checking conveniency, in style of LillyDAP
   - Parts of the fields could be harvested (e.g. labeledURI's two pieces)
   - This is probably best as a separate wrapper API calling generic code
   - Split into separate .o as much as possible, for compaction of .a

* Have a dictionary API to manipulate controls; gperf may be used here too

* Support builds to be completely out-of-source
   - Broken by the mapping from `.gperf` to `.tab`
   - Broken by the imported `openpa` which is extracted and configured