Update `README.md`, use `synopsis.js` for landing.

I've decided to use `synopsis.js` for a Docco landing page. Got the tests
passing to canned formats.

Updated to `README.md`
----------------------

As far as the `README.md` itself, here's a case where you really ought to just
view the diffs to see what changed, or simply proofread the before and after
versions. During the course of beefing up the `README.md`, I noted that I added:

 * Notes on other libraries.
 * Notes on "setting timezone" in motivations.
 * Notes on natural language processing and parsing offsets.

Using Correct Timezone to Fill in Date
--------------------------------------

Working though the `README.md`, as I speak to the [Rubber
Duck](http://www.codinghorror.com/blog/2012/03/rubber-duck-problem-solving.html),
I find things that I thought I implemented, unimplemented. Parsing does not take
wall-clock time into account, for example.

Noticed that the `makeDate` doesn't account for timezone when the date is
omitted.

    tz('23:30:00', 'America/New_York')

The date should be calculated using today's date in New York, so if you said
12:00 in New York when the system clock says 02:00 UTC, it would take system
time, adjust it by -04:00 and know it is yesterday in New York still. That is
the date you should use, New York's date, not UTC.

I created issue #3 to address this.

StackOverflow Articles on Time and Daylight Savings Time
--------------------------------------------------------

While writing and researching, I found a good Stack Overflow article about time
in applications, [Daylight saving time and Timezone best
practices](http://stackoverflow.com/questions/2532729/daylight-saving-time-and-timezone-best-practices).
Need to read though this and put its excellent help into the documentation, in
`MOTIVATIONS.md` or maybe a new document that talks about how to use time in an
application.

Moving clocks back gives two of the same hour. Curious about this ambiguity at
the end of daylight savings time, I started tarted a StackOverflow question.

> Have you ever had to distinguish between the first and second occurrence of an
> hour at the end of a daylight savings time? How did you represent that in your
> user interface?

> At the end of daylight savings time, we move our clocks back an hour so that
> the hour repeats. I've seen...

Then Stack Overflow suggested this pair of questions, the same question once at
Stack Overflow, [How to enter time at DST
changeover?](http://ux.stackexchange.com/questions/16826/how-to-enter-time-at-dst-changeover),
then again at UX Stack Exchange, [How to enter time at DST
changeover?](http://stackoverflow.com/questions/9094973/how-to-enter-time-at-dst-changeover).

I'm seeing that this is always a UX challenge, once someone comes face to face
with it. Probably takes a daylight savings time shift with a calendar
application in the field to notice it. 23 hour and 25 hour days, these cause
problems for shifts and schedules.
Merge branch `release-0.0.9` into `readme`.
Merge branch `master` into `readme`.
Synopsis rough draft.

Got a feel for what I'm trying to say in the synopsis, and how I'm going to say
it. I'm about to delete a bunch of repetitive stuff, so I'm going to commit what
I have.

Able to move away from discussing motivations. Trying to imagine myself writing
for people who've already adopted the library, or rather, who've already adopted
the practices espoused by the library, and are looking to see how it use it.
Second draft of synopsis.

Definitely in the order I need it to be in, with all the unused stuff
gravitating toward the bottom the of document.

This document has a lot of examples that are US examples. I'd like to use more
examples from other parts of the world, once I get the synopsis working. I can
imagine that people looking for localized dates will be reassured to find
examples using locales and timezones outside of a single country.
Merge branch `master` into `readme`.
Convert to plain text `README`.

Replace our jumbled, confused and out of date markdown `README.md` with
a plain ASCII `README` that directs the visitor to the GitHub:Pages.

Fixed bug in `synopsis.js`.
Merge branch `merge-date.js` into `master`.
Merge branch `readme` into `master`.
Convert to plain text `README`.

Replace our jumbled, confused and out of date markdown `README.md` with
a plain ASCII `README` that directs the visitor to the GitHub:Pages.

Fixed bug in `synopsis.js`.

This is an attempt to keep messages between here and issues up to date
by closing this with the command below. I'm curious to see how much this
alters the git history.

Closes #37.
Merge branch `readme` into `master`.
Size savings searching clock transition day.

In `actualize`, when searching for a last occurrence of a day of the
week in a particular month, it is not necessary to test that the month
is indeed the desired month. This test was because we always set the
last day of the month to 31. We now set it to the actual last day of the
month for the specific month.

Fortunately, there is no rule that requests a clock transition on a last
day of the month in February, where the day of the week happens to also
be the same day of the week March 1st on a non-leap year. We assert that
this is true in `bin/zones.js`. If it were the case, then removing the
month test would cause the lookup to fail because on a non-leap year,
creating a day with a month of February and a date of 29 would create a
March 1st date, the day of the week would be correct, and the loop would
exit on the 1st March, instead of February 22nd.

Also in `actualize`, we indicate an exact date by setting the desired
day of the week to seven because less than seven compresses better than
grater than or equal to zero.
Merge branch `last-day` into `travis-ci`.