Declare generated functions to use shadow-stack GC

I doubt this significantly effects the generated code but it's a
requirement to use LLVM's GC intrinsics
Add TempValue.isGcManaged and ps.DisposeValue

TempValue.isGcManaged indicates if a value should be a GC root. All temp
values storing cell values will be annotated as GC roots.

ps.DisposeValue instructs codegen that a value will not be used again.
This eventually can be used to un-GC root values.
GC safe code generation across function calls

This is untested against and actual GC but it doesn't cause any
regressions on unit tests. Cell allocations are the other GC barrier and
are currently unhandled.
GC barrier support for cell allocations

This generalizes the GenGcBarrier logic and updates GenCellAllocation to
use it to save/restore GC roots in the garbage collecting path.
Add DisposeValues conniver pass

This disposes of unused values as soon as possible. This greatly reduces
the overhead of GC as only truly live values need to be rooted.

This changes ps.Invoke to take an InvokeArgument which indicates if the
TempValue should be disposed after the invoke. Disposing before the
invoke would make the argument inaccessible and disposing after would
mean it would be rooted for the duration of the call. The only way to
avoid rooting one-off argument values it to dispose them as part of the
invoke.
Create GC slots on demand

Instead of creating a GC slot for every possible GC managed value only
create a slot when a value needs to be restored across a barrier. This
allows us to significantly reduce the number of slots required. We also
know the type of the value so we can remove the casts to/from %datum*.
Immediately dispose of unused arguments

If the arguments aren't disposed they'll be saved and restored across
every GC barrier in the function. Usually unused arguments indicate
dubious code but it's possible macro expansion coudl create them.
Mark new cells as GC allocated

This gets rid of the old white/black designation inherited from Llispy
and instead uses constant/allocated/forwarding. This is to support a
more simple semi-space GC as opposed to Llispy's intended mark-sweep GC.
Remove preallocCells

preallocCells() is a legacy for when only single cell allocations were
supported. The intent was to preallocate the number of required cells to
reduce GC overhead. Now that ranges can be directly allocated from the
GC it no longer has a usecase.
Switch create(Proper)?List use std::vector

Previously they were accepting std::list<> probably due to my Qt brain
damage. std::vector<> is more efficient here but more importantly the
vector can be easily GC rooted across the GC allocation for the list's
pairs.
Rename alloc::Cell to alloc::AllocCell

"Cell" is an ambiguous name and could imply a generalization of
DatumCell. Tename to AllocCell even though its in the alloc namespace to
clarify that is it allocator related
Simple first pass of garbage collection

This provides three classes to allow the runtime to cooperate with the
GC:

- alloc::StrongRef is a strong reference to a GC managed object. These
  act as GC roots and the pointer values are automatically updated to
  their new location
- alloc::WeakRef is a weak reference to a GC managed object. These are
  not GC roots but do have their pointer values updated if the value is
  otherwise reference
- alloc::StrongRefRange will GC root a range of externally allocated
  root pointers. This has a few minor use cases related to constructing
  lists and vectors

When the current semi-space is exhausted a new semi-space is allocated
and alloc::visitCell() is used to visit each reachable cell and move it
to the new semi-space. Any weak references to live cells are then
updated to point to the value.

The runtime remains completely GC unsafe. The next commits should
resolve the most obvious issues.
Rename _lliby_alloc_start to _lliby_alloc_next

_lliby_alloc_next moves forward with every allocation, similar to a
stack pointer. _lliby_alloc_start seems to be more indicative of a
static value and could be confused with the semi-space start.
Make the bindings and their unit tests GC safe

This ensures that all datum pointers are properly referenced before
allocating any values. All unit tests now pass with GC and
_LLIBY_ALWAYS_GC enabled.
Explicitly give a body for _lliby_alloc_cells

The previous method of aliasing the name didn't work (on Mac OS X 10.9
at least). There was also a potential issue on 32bit systems where the
compiler was expecting it to take std::uint64_t while the function was
actually taking a size_t

Fix by giving _lliby_alloc_cells a function body that just directly
calls allocateCells. This is a slow path so it shouldn't make any
measurable difference.
Crawl the GC roots provided by the compiler

This will respect and update any GC roots provided by codegen. With this
commit trivial cases of GC actually work correctly: over 95% of the
functional tests pass with _LLIBY_ALWAYS_GC enabled.

The major holes now are GC unsafety in the stdlib and support for
record/procedure types.
Initial GC safety fixes for stdlib

- Make (list-copy), (cons), (vector) and (apply) properly root live
  values across allocations

- Remove InexactRationalCell and ExactIntegerCell's constructors and use
  a static ::fromValue() instead. This fixes places where the allocation
  was happening first then the constructor arguments were computed using
  an invalidated pointer to another cell.
Improve external form for procedures

- Include the entry point for the procedure in the external form

- Distinguish procedures capturing variables (#!closure) from those not
  capturing ($!procedure)

This is primarily intended to help debug garbage collector issues but
should be generally useful
Add _LLIBY_NO_ADDR_REUSE

This is an additional GC debugging flag that causes the allocator never
reuse semi-space address space and instead discard its pages and mark it
as unreadable. Otherwise the same address space will likely be reused
for a later allocation and stale pointers might silently keep working or
cause delayed misbehaviour.
dumpReachableFrom enhancements

- Prefix dumped data with their memory address. This is useful for
  correlating with GC backtraces etc.

- Add a flag to disable the dumping of global constants. These are
  generally uninteresting when debugging garbage collection

- Track which cells we've dumped and don't dump them again if they're
  reachable from multiple cells.