compiler: Introduce vt.{NonRecursiveType,LeafType}

These are used to help pattern matching types.

Leaf types are types that contain no references to other types. These
include native types and Scheme type atoms.

Non-recursive types are leaf types and types that have recursion
explicitly disabled due to implementation restrictions. These are
record types and applicable types.
compiler: Limit list type constructors

vt.UniformProperListType and vt.SpecificProperListType were taking
recursive type references for their member types. However, these
recursive references had to be specifically relocated depending on their
position on the list. This was done manually in ExtractType but it would
be nearly impossible for any other caller to do correctly.

Instead, have vt.UniformProperListType and vt.SpecificProperListType
only take direct types. This is suitable for all callers except
ExtractType. Then, have ExtractType build its list types directly with
the proper recursive reference relocations.
compiler: Add ResolveTypeVars

This is the basis of the polymorphic type system. It takes a polymorphic
type and an evidence type and attempts to derive the type variables for
the polymorphic type.

This is unused outside of its unit test - there is currently no way to
declare a polymorphic type.
compiler: Add ReconcileTypeVars

- Move polymorphic type functions to valuetype.polymorphic package

- Introduce TypeVar. This is just a wrapper around the upper type bound
  for the variable

- Add ReconcileTypeVars. This takes a list of resolved type variables
  and their type variable definitions. It ensures each resolved variable
  doesn't violate the type bounds of the defined variable and fills in
  any missing variables with their upper type bound
compiler: Add InstantiateType

This is a thin wrapper around UnrollType that instantiates a polymorphic
type with the passed type variables
compiler: Remove vt. prefix in valuetype package

There is no point importing our own package with a prefix and then
inconsistently using it in the file.:
compiler: Change polymorphic vars implementation

Instead of using recursive type references to represent type variables
use a placeholder record type. This has a number of advantages:

1) Record types can be used anywhere in a types structure, just not at
   recursion points. This allows type variables to appear in union types
   and procedure types even though they don't support recursion.

   There will still be some restrictions on the use of polymorphic
   variables for resolution. For example, resolving a union type with a
   polymorphic variable doesn't seem sane and likely won't be supported.

 2) Polymorphic types can be naturally printed using NameForType without
    explicit type variable support

 3) The ordering of type variables and their association with recursion
    depths was subtle and fragile. This will also make merging
    polymorphic types easier if that's ever supported.
compiler: Make UDT constructors use polymorphism

This ports the user defined type constructor infrastructure to use
polymorphic types. This has a number of advantages:

- This parses the constructor's definition at construction time instead
  of at instantiation time. This catches invalid type constructors even
  if the constructor is never instantiated

- This lets us support upper type bounds on user defined type
  constructor arguments

- It reuses part of the infrastructure that polymorphic procedures will
  use which will allow for more testing and common functionality.
compiler: Add PolymorphicSignature

This is the polymorphic analogue of ProcedureSignature. There are two
methods provided to convert to a ProcedureSignature:

- signatureForOperands will resolve and reconcile the signature type
  based on the passed operands

- upperSignature will resolve the signature using the upper type bounds
  for every type variable

This is used throughout the planner instead of ProcedureSignature.
However, the polymorphic functionality is unused at this point.
compiler: Support polymorphic native functions

- Add support for an (All) type constructor for native functions. This
  works identically to the same type constructor in Typed Racket

- Have PlanInvokeApply instantiate an extact signature for its passed
  arguments. I'm unsure if this is the correct level in the application
  process to handle polymorphism but it appears to work

- Make (reverse) polymorphic on its passed list type for testing
  purposes
compiler: Support resolving type vars directly

Previously we would only resolve type variables in a position that
allowed recursive type variables. Instead, allow them to appear directly
wherever any Scheme type is allowed
First pass of polymorphic conversion and fixes

- Fix SingleValue.withReturnType to actually use the passed type

- Move polymorphic selection logic up to PlanApplication so we only need
  to override the return type once. This also fixes an issue where
  PlanInvokeApply was creating TempValues of the wrong type for
  polymorphic functions

- When resolving and reconciling type variables for procedures simply
  default to the upper bound if the upper bound is violated. This fixes
  things like (+ value 1) failing where "value" is an untyped mutable
  because <any> would be inferred for the type

- For procedures always preserve the applicable type of the type
  variables. This means that (cons A B) isn't considered to return a
  pair of specific procedure types if A or B has a specific procedure
  type. This matches what happens in reality - we will convert the
  arguments to the applicable type of the procedure's upper bound.

- Fix crash if we tried to use EmptySchemeType as evidence

- Convert more of the stdlib over the polymorphic type declarations
Further polymorphic conversions

This converts (vector-ref), (make-list) and (list-tail) to be
polymorphic. It also fixes InstantiateType to properly create the top
vector type for (Vectorof <any>).
compiler: Clean up NameForReturnType

- Remove unreachable clause

- Fix whitespace
compiler: Parameterize vt.ReturnType

vt.ReturnType was used to represent both Scheme return types (as in
procedure types) and native value return types (as in native function
declarations). As there was no distinct type or type extraction code for
the two cases they could be freely mixed with interesting consequences

Instead parameters ReturnType so it can be either a
ReturnType[ValueType] or ReturnType[SchemeType]. Appropriate type
annotations actually make this fairly painless. The only major code
change required is separating ExtractType.extractReturnType in to
extractReturnSchemeType and extractReturnValueType