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`.