Great type renaming and name unification

The original type system grew out of the requirements of the NFI. In
particular, native types like <int64> were given short names and any
cell-based type was given a type suffixed with -cell. This continued
even when the frontend would sometimes choose native types (such as
<int64>) as a compact representation for another type (such as
<exact-integer-cell>)

This was partially resolved by adding Scheme level aliases from the
internal <*-cell> names to shorter names based on what Typed Racket
used. This presented a number of problems:

- Error messages would still use the original underlying type which was
  confusing

- Internally the types were referred to usually by their original names
  in some cases were far away from their common name (i.e. <flonum>
  versus InexactRational)

- There were effectively two namespaces for types, one intended for use
  by NFI code and one used for Scheme code.

- Internal libraries that were unable to import (llambda typed) either
  has to use the <*-cell> names or have an private internal type alias.

Fix this by:

- Removing all the <*-cell> suffixes from the cell type Scheme names

- Rename the stdlib's datum_*_cast functions to cell_*_cast

- Rename InexactRational => Flonum, Character => Char, Datum => Any

- Change the <integer> type to <exact-integer> which is a bit more
  accurate at the expense of being verbose
compiler: Add vt.NameForType

This replaces ValueType.schemeName with a separate NameForType function
and set of unit tests. This has a number of purposes:

- If recursive types are supported NameForType will likely have to track
  state to insert recursive type variables where required. This would be
  ugly with .schemeName

- Due to ValueType being sealed all of its subclasses have to be defined
  in ValueType.scala. This allows us to move some code out to a separate
  file to reduces ValueType.scala's size

- There was no comprehensive unit test for Scheme type names. This adds
  one
compiler: Pair and proper list type fixes

These were encountered while attempted to re-implement proper lists on
top of a general recursive type system. However, these are correctness
fixes for the type system even in the existing implementation

- If just the car or cdr of two pair types definitely do not satisfy
  each other then the pair types themselves do not satisfy each other.

- Two proper list types can potentially satisfy each other even if their
  member types are disjoint. This is because the empty list itself isn't
  typed so an empty list of one list type will satify any list type.

  This makes me uneasy as it weakens our type system but it reflects the
  reality of how our data structures work

- The empty list type satisfies all proper lists. This means that
  otherwise completely incompatible proper lists should return the empty
  list when intersected.

- Subtracting an incompatible proper list from another proper list means
  the original proper list is non-empty. Fix by returning a pair type
  with the member type as the car and the proper list type as the cdr.

- Fix intersections between unions containing subtypes