stdlib: Reformat comment for lliby_list

This is a leftover from our old 80-column limit
compiler: Introduce vt.SpecificProperListType

- Rename vt.ProperListType to vt.UniformProperListType. This is
  analogous to vt.UniformVectorType

- Factor out the (Listof) constructor logic to a
  vt.SpecificProperListType function. This will be useful for multiple
  values as it needs to generate type checks for value results in some
  situations
Initial infrastructure for multiple return values

Note that this does not work correctly due to there not being a way to
indicate that runtime functions such as (apply) return multiple values
now.

- Introduce ReturnType that indicates the return type from a procedure.
  Currently we support three classes of return types:

  * SingleValue is effectively identical to our previous return type
    support. One exception is the previous return type of None is now
    SingleValue(vt.UnitType)

  * SpecificValues is fixed size of return value of specific types. This
    is what the theoretical (values) type constructor would build

  * ArbitraryValues is a set of zero or more return values. This is what
    procedure trampolines and things like (apply) will return

- Introduce planner.ResultValues which is similar to IntermediateValue
  but for result values. This wraps a BoxedValue and ReturnType and can
  convert to IntermediateValues to different ReturnTypes

- Add TempValueToResults to convert a {TempValue, ReturnType} to a
  ResultValues instance

- Have PlanResult contain a "values : ResultValues" member instead of a
  "value : IntermediateValue". This allows PlanResult to pass back
  multiple result values. This is the source of the majority of the code
  churn

- Switch AdaptedProcedureSignature to return ArbitraryValues and port
  PlanProcedureTrampoline to use some common infrastructure with
  PlanInvokeApply
Support for specifying multiple value returns

- Add ExtractType.extractReturnType that will parse a type and return a
  ReturnType.ReturnType. This is required because the multiple values
  "types" aren't types at all and can only be used in the return type
  position.

- Treat "*" symbol as an ArbitraryValues return type. This seemed
  appropriate as "*" is already a reserved symbol for rest argument
  lists

- Add special type constructor "Values" to create SpecificValue return
  types. This is the same as the constructor used in Typed Racket

- Properly annotate functions (such as (apply)) that return arbitrary
  values in stdlib.scm

- Add "ReturnValuesList" typedef for "ListElementCell" in the runtime to
  make it clear where a return values list is being handled
runtime: Have continuations take multiple values

Instead of tracking a single passed value through a continuation take a
list of passed values. This isn't directly accessible without
(call-by-values). This does allow the unit tests to pass again, however.
Implement (call-with-values)

This provides the final piece of core multiple value support. This is
still quite inefficient but the next few commits should optimise
(values), (call-with-values) and (apply)
stdlib: Optimise (values) implementation

Instead of using the suggested implementation in R7RS that uses
(call/cc) we can simply have a function that returns its rest argument.
Because value lists are just proper lists of values this works without
any allocation or type checking.

Add a functional test to ensure passing multiple values to an escape
procedure continues to work.
compiler: Factor out car/cdr loading

This moves the logic for planning (car) and (cdr) out of CadrProcPlanner
in to a new PlanCadr and cleans up the code a bit. This is so the
upcoming code for applying with an argument list can reuse the known
pair and typing logic.
compiler: Better planning of (apply)

(apply) without a known argument list would previously unconditionally
bounce through a procedure trampoline even if the exact signature of the
calling function was known. This was suboptimial but tolerable before
multiple values but now procedure trampolines need to allocate to place
single values in an arbitrary values result list.

To fix this factor out the trampoline planning code in to a new
PlanInvokeApply.withArgumentList. This will use type information from
the passed list value to remove type checks where possible. It will also
return the ResultValues from the function directly instead of placing it
in an ArbitraryValues list unconditonally.
compiler: Add planning for values procedures

This adds inlining planning for (values) and (call-with-values).
Unfortunately it can't plan the producer and consumer procedures inline
but it can skip type checking and indirection through procedure
trampolines when possible.
compiler: Simplify multiple values logic

Instead of having distinct "SpecificValues" and "ArbitraryValues" return
types just have a single "MultipleValues" return type that takes a
list type. Have planner.MultipleValues take an intermediate value which
encodes both its boxed value and type.

This has a few advantages:

- Type checking multiple values list becomes trivial as the expected
  type of the list and the intermediate value to check are both
  directly available

- Converting proper lists to and from multiple values list become much
  easier as they both deal with IntermediateValues

- In the future more complex values types are easy to introduce as any
  proper list type can be used as a return type
compiler: Reduce multiple value (call/cc)

Generalise ReduceCallCc to deal with (call/cc) taking multiple return
values. This doesn't properly type the return arguments but at least
avoids invoking (call/cc).
compiler: Plan call-with-values in PlanApplcation

We can use the same hacky infrastructure in place for (apply) to allow
inlining of applied procedures to plan (call-with-values). In the best
case this allows both (lambda)s to be stripped away and the multiple
value list to not be generated in IR.
compiler; Multiple value improvements

- Use a more descriptive error message when attempting to convert a zero
  length value list to a single value

- Properly locate error messages for (call-with-values)

- Add functional test for nested (call-with-values) and zero length
  value lists

- Plan (values) even at -O 0 because we need the planner to extract
  useful type information

- Rename RetypeLambdaArgsSuite to LambdaSignatureSuite and add two tests
  for returning multiple values