compiler: Fix GC slot counting with CondBranch

- Clean up the names in GcState.fromBranches to reflect that we're
  dealing with the "continuing" state along with non-continuing states.
  During a normal branch the continuing state is the parent state but if
  only one branch terminates then we'll continue off of that branch's
  state.

- Consider the continuing state when determining the next unallocated
  slot number. If only one branch terminates its GC slots weren't being
  accounted for. This caused invalid LLVM IR to be generated as the slot
  wasn't created in the function prologue

- Add functional test that triggers the buggy behaviour at -O 2
compiler: Avoid GC flush if branch terminates

If one or both of our CondBranch branches unconditionally terminates we
don't need to merge our GC state once the branch completes. This means
we don't need to flush our GC state before the branch.

This is useful for tail recursive procedures that take GC managed
arguments. Before, we would create a shadow stack entry and root the
argument before the conditional branch containing the tail call even if
there was no other GC usage in the procedure.
compiler: Fix mutually recursive type pred procs

This was encountered as a sporadic failure planning the type predicate
for (Listof <any>). Due to another issue the order which union member
types are tested in a type check is undefined. Sometimes (Listof <any>)
would be planned as:

- Check for <empty-list>
- Check for (Pairof <any> (Listof <any>))

The Pairof test would attempt to perform another test for (Listof <any>)
but it wasn't aware that test was already being planned. The result was
the generation of an unbounded number of type predicates until the Scala
stack was exhausted.

Instead of building the type predicate system around
KnownTypePredicateProc move the equivalent functionality in to a
dedicated SymbolForTypePredicateProc function. This function will note
the allocated symbol for a type predicate proc before it starts planning
that proc which allows an arbitrary number of recursive type predicate
procedures to be planned at once. The hack in PlanTypeCheck to deal with
self-recursive type predicates has been removed as the more general fix
now covers it.

For some reason this is difficult to trigger during functional tests.
There is some upcoming tests for other features that trigger this about
50% of the time that will hopefully be sufficient to catch this in the
future.
compiler: Prefer unboxed arguments for lambdas

The justification behind accepting boxed types was that if the caller
had already allocated a box for the value we wanted to re-use it instead
of causing another allocation. This was chosen over the downside of
potentially having to force the caller to allocate if it didn't already
have a box.

A few things have changed since that decision:

- The type system and explicit typing is much more sophisticated.
  Presumably performance sensitive code will use type annotations that
  avoid having to explicitly box values in most situations

- We support more inline planning for operations such as integer math.
  These typically operate on and return unboxed values

- Because of #1 and #2 tail recursive procedures using e.g. integer
  accumulators or counter need to box a value simply to tail call
  themselves. Now that somewhat efficient tail calls are supported this
  is a barrier to implement stdlib behaviour using tail recursion
compiler: Enable tail call optimisation at -O 0

- Run the FindTailCalls conniver pass at all optimisation levels

- Pass tailcallopt to llc and opt to ensure it generates tail calls
  where we request it

- Add a simple functional test to ensure a tail calls can work correctly
  for 500000 iterations. This test is non-allocating which is important
  for it to complete in reasonable time with GC debugging enabled.
compiler: Fix integer math at -O 2

We were passing nuw (no unsigned wrap) to our integer arithmetic
instructions. Because we deal with signed values (LLVM has no concept of
signedness in its type system) passing nuw is incorrect and led to
undefined results for signed values that did not wrap.

Add a test that initially showed this issue. This is tricky to test
because most trivial tests will get collapsed in to a compile time
    constant.
compiler: Remove _lliby_fatal

It's no longer possible for codegen to trigger fatal errors. The runtime
internal fatalError exists for runtime usage.
runtime: Fix invalid write in fromUtf8Data

StringCell::fromUtf8Data was setting the byte past the end of the string
to NULL. At one point this was correct as our strings were expicitly
allocated to have one extra NULL byte but this was changed in 7104775.
Due to our sized malloc implementation this wasn't caught with Valgrind
on any of the tested platforms

- Fix the invalid NULL write by simply removing it

- Fix the broken unit tests in test-bytevector that were reading past
  the end of the bytevector

- Add a test in test-string that first does a probe allocation to figure
  out which size malloc the OS will return. It will then due an
  allocation of exactly that size. This will still pass even with the
  invalid NULL write but it will at least show up in Valgrind.
runtime: Add StringCell::fromUtf8StdString

This is a trivial wrapper around StringCell::fromUtf8Data
Include file and line in runtime error messages

This extends signalError and its codegen entry point _lliby_signal_error
to include "path" and "lineNumber" arguments. These are appended to the
error message at runtime based on the source location of the plan step
that is generating the error. This reuses the same location tracking
that debug info generation uses so it's fairly simple to implement.

The file and line number are passed separately instead of being baked in
to the message string to allow the error messages and path strings to be
reused across multiple messages. In the future that information could
also be explicitly included in the error object.

Closes #45