dumpReachableFrom improvements

- Rename showCells => shownCells

- Don't compile in release builds. Due to the use of <iostream> a lot of
  code is generated for this simple looking function.

- Use std::unordered_set instead of std::set for shownCells. We don't
  need ordering and an unordered set is more efficient for the
  operations we want to perform.
Support for runtime created record-like classes

- Add dataIsInline to RecordLike constructors

  This makes it possible to sanely generate RecordLike values from the
  runtime. Before the dataIsInline member would just be uninitialized
  which will crash the GC

- Add RecordLikeCell::registerRuntimeRecordClass()
  This allows the runtime to create its own procedures with closures
  referencing GC managed cells. This is completely transparent to the
  GC itself.

- Add RecordLikeCell::allocateRecordData() that wraps the malloc() that
  was previously in core/recorddata.cpp. Update recorddata.cpp to call
  allocateRecordData() instead

- Add protected setRecordData() function to allow setting the
  appropriate record data pointer.

- Add unit test for record-like garbage collection based on the runtime
  RecordLikeClass support
Use correct include guard for fatal.h
Dynamic state runtime support

This adds a ParameterProcedureCell class to the runtime which is a
normal ProcedureCell with accessors for the contents of its closure.

There is a list of State objects which link to their parents.  Whenever
a parameter procedure is invoked it will walk up the active state's
ancestors. If no value is found it will return its initial value.

Dynamic states can optionally have before/after procedures associated
with them. This is used to implement (dynamic-wind). (dynamic-wind) is
currently equivalent to calling before->thunk->after but attaching it to
the state infrastructure will make it easier to implement continuations
and exceptions

The garbage collector will also crawl the state list and root all
values referenced by the state as well as update their pointers.

The new compiler-facing functions are:

- _lliby_dynamicenv_push creates a new child environment and makes it
  active

- _lliby_dynamicenv_set_value sets the parameter in the active
  environment to the passed value

- _lliby_dynamicenv_pop restores a previous environment
Compiler support for parameterize

This required some generalization and refactor of the compiler to
support new control structures:

- Factor out most of createLambda to extractBodyDefinition. This can be
  used to process the body of any body-like definition such as (lambda),
  (parameterize), (guard), etc

- Add a ps.NestedStep that generalizes steps containing other steps.
  Most intermediate steps dealing with ps.CondBranch now deal with
  ps.NestedStep

On top of this fairly direct processing of (parameterize) is added. It's
extracted by the frontend to an et.Parameterize which is then planned in
to a ps.Parameterize. The codegen simply directly pushes a new dynamic
environment, sets the values, generates the inner steps, then pops the
state.
Change the external form of procedures

- Change #!closure() to #!parameter(closure:<proc>/<entry>). This makes
  closures with the same entry point distinguishable

- Change #!procedure() to #!procedure(emptylclosure/<entry>) to parallel
  the closure form

- Distinguish parameters as #!parameter(parameter:<proc>)