## Nanomath core

The organization here is to keep the core engine as compact and as agnostic
as to what sort of functions and types there might be in a TypeDispatcher as
possible. This division will keep it plausible to break out just the core
as a TypeDispatcher package that could be used independently for any collection
of overloaded functions on a universe of types. So we want to place as few
assumptions/preconditions as to what functions and/or types there will be.

## Core Types

As of this writing, the only two types required to be in a TypeDispatcher are
Undefined (the type inhabited only by `undefined`) and TypeOfTypes (the type
inhabited exactly by Type objects).

There is also a constant NotAType which is the type-world analogue of NaN for
numbers. It is occasionally used for the rare behavior that truly does not
return any particular type, such as the method `zero` that takes a Type and
returns its zero element. However, it does not really work as a Type, and in
particular, do _not_ merge it into any TypeDispatcher -- it will disrupt the
type and method resolution process.

## Core methods

Similarly, as of this writing the only methods that must be in a TypeDispatcher
are:

Type
:   the class (constructor) for Type objects, called via `new Type(...)`.
    Note that merely constructing a Type does not regeister it within any
    TypeDispatcher; it must be `.merge()`d into the TypeDispatcher.

typeOf
: determines the type of any value

merge
: adds values and methods to the TypeDispatcher

resolve
: finds values and methods in the TypeDispatcher, by key and types list

Any (other) functions an instance wants to have acting on the core Types
should be defined elsewhere and merged into the instance.

In nanomath as a whole, rather than within its core, we also assume that
the NumberT type of regular JavaScript numbers is always present (i.e., no
need to check if it is in the instance), and we put all functions that we
want to define on the core Types in the coretypes directory.