compiler: Support for inlining with captured vars

This allows captured variables to be loaded from a closure for the
purposes of inlining. The closure's structure is persisted in a new
LambdaClosure case class and closure loading is factored out in to a
LoadClosureData function. AttemptInlineApply will look for variables
that it can load from the closure and use LoadClosureData to load them
if possible.

This is generally useful but it's primarily part of groundwork for
polymorphic lambdas. The upper bound instance will build the initial
closure and the specialised instances will load variables from that.
compiler: Support for annotating polymorphic procs

This is unused by the planner at the moment. It's just wiring up the
frontend support for polymorphic type annotations and updating any
affected code and tests.

- Add PolymorphicProcedureType. This is closely analogous to
  PolymorphicSignature except it's intended for use in Scheme types
  instead of procedure signatures.

- Expand the type annotation system to allow declaring polymorphic
  types. ExtractLambda is then extended to take a polymorphic type and
  properly pass it through to the expression tree.
compiler: toApplicableValueFor{Arity => Operands}

This takes a list of operand types instead of simply an operand count.
This will allow polymorphic lambdas to be resolved in the future.
Initial support for polymorphic Scheme procs

This splits PlanLambda in to two parts:

1) PlanLambda itself calculates the captures and builds a closure for
   the procedure. The result of this is a LambdaManifest containing the
   essential information about the lambda

2) PlanLambdaPolymorph is then called with the LambdaManifest and the
   upper bound type for the procedure. This results in an
   iv.KnownSchemeProc with the upper bound of the polymorph - this is
   known as the "primary polymorph" and owns the closure.

When toApplicableValueForOperands is called on a polymorphic
KnownSchemeProc it will attempt to instantiate its polymorphic type for
those operands. If that differs from the upper bound it will then create
a secondary polymorph:

1) PlanLambdaPolymorph is called with the instantiated type to produce a
   entry point. A flag is passed to indicate that "self" is an adapater
   procedure and the primary polymorph needs to be loaded from the
   adapter to access the original closure

2) An adapater procedure is returned containing the polymorph's entry
   point and a pointer to the primary polymorph
compiler: Resolve polymorphs when converting procs

When converting to a procedure type taking only fixed arguments we can
select a specific polymorph to use based on
toApplicableValueForOperands. This has two main effects:

- For polymorphic Scheme procedures we can generate a polymorph exactly
  matching the requested types. This can generate more efficient code by
  simplifying trampolines and removing type checks.

- For case lambdas we can select the exact case lambda clused requested.
  This reduces the overhead of dispatching through the parent
  (case-lambda)

This also fixes a bug where (apply) was sometimes selecting a polymorph
using its own arguments when the actual arguments were unknown.
compiler: Add test for recursive polymorphs

This tests that recursive polymorphs have the correct self value with
the expected signature. This already works but it's worth testing to
prevent future breakage.
compiler: Remove overqualified imports

If we import io.llambda._ we should refer to "io.llambda" as just
"llambda".
stdlib: Make rounding procedure polymorphic

These procedures always return the same type they receive
comiler: Introduce ps.MutableRead

This indicates that a step can be discared if its result is unused but
it cannot be merged with other steps. This is both a performance
improvement and a bugfix:

- LoadRecordDataField was marked as NullipotentStep in bc1e105 which is
  incorrect for records with mutable fields. This means writes followed
  immediately by reads could potentially use the old value. In practice
  this didn't happen because every record field load has a dependency on
  a unique record field load which isn't mergeable

- LoadPairCar, LoadPairCdr, LoadProcedureEntryPoint and
  LoadVectorElement can be marked as MutableRead. This allows them to be
  discarded if their result is unused.