Create `README.md` from `timezone.idl`.

Created a `README.md` from `timezone.idl`. Going to create an
[Edify](https://github.com/bigeasy/edify) web site that will be the canonical
documentation. The essay on motivations, on dates and object orientation, will
be moved onto a separate page. It will get me to release faster to push that off
to the side and focus on documentation first.

Ran the Vim spell checker against `README.md` while I was at it.

Moved the `README` objectives into an **Objectives** section at the bottom of
the `README.md` page.

Did some writing, but stopped myself. Didn't feel like writing about motivations
any further. Motivations need to be a separate essay and not part of the
overview and introduction.

Almost completed #2.
Split out motivations from `README.md`.

Moved the defensive documentation into an essay. The landing page of the
GitHub:Pages site will be an overview with examples, not a diatribe against
object-orientation.

I don't know that I'm being fair to myself. The world is coming around to a new
way of coding. I don't know that my writing it too defensive. I'm imagining
some unimaginative people saying that the `Date` object is a convention.

The defensiveness is directed at an imagined argument that I am reinventing the
wheel. Of course, I can't stand that particular argument. It is an argument
against new implementations.

The argument against the `Date` object is not as important as showing how to use
the `tz` function, how much easier it is to use than `Date`. It is a lot of
functionality packed into a small package.

Going forward, I'm going to keep documentation off to the side. I'm going to
work on it for an hour or two a day. It is not getting finished. Probably
because it is still charged with emotion of my transition to JavaScript from
Java.

I'm able to get other projects documented, done. Strata, for example, is getting
documentation as I move along. Proof is well represented in its `README.md`. The
latter being a brand new project. Instead of touting the faults of existing
testing frameworks, I'm touting the benefits of Proof.

This has to be the approach of Timezone, if I'm going to get it documented. Say
something along the lines of...

Instead of monkey patching the JavaScript `Date` object, to create a method
chained monster, we have a single function, with a short name, `tz` that
operates on POSIX timestamps and date strings. One function can parse, format
and calculate dates. Give it a handful of human readable parameters, it will
figure out what to do.

That sort of cheery, now how much would you pay? banter is easier to write,
probably easier to read, and encourages participation from people based on the
benefits of Timezone, instead of inviting an argument about object orientation.

Let people come to the idea that object oriented `Date` is a kludge on their
own.

More progress #2. Although there is no Docco yet. That will come out of the
`gh-pages` branch.
Add `milliseconds` to date math.

Currently, date math will recognize `milli` and `millis` as a unit of measure in
date math operations. Added `millisecond` and `milliseconds` as synonyms, since
I found these units in the `synopsis.js` test program. That must be what I want
if I called for it while considering the API.