Use `timezone` as `require` root.

Purged the binaries I'm no longer using, including the 7-bit format
complier. I had a script to inspect the properties that I've deleted.

Perhaps I'll read through it and add it to `bin/zones.js` as assertions.
Perhaps the unit tests are assertion enough.

Updated `Makefile` to build the NPM package in a `timezone` directory.
The build step is necessary to build the Olson as JavaScript files. We
now keep them relative to the root of the directory, meaning the package
itself is cluttered. We have a build step so we don't have to work in
the clutter.

This also allows me to write my tests using the `require` search path.
Test must be run with a search path of `NODE_PATH=.` so it will find the
`timezone` directory.

Updated the `package.json` to test using the `timezone` directory.

Zone and locale files are now in the root directory of the packaged
Timezone library published to NPM. This means that an application can
require a locale using `require("timezone/pl_PL")`, or require timezone
data using `require("timezone/America/Detroit")`.

This is less verbose than `require("timezone/zones/America/Detroit")`,
but still not as terse as `require("zones/America/Detroit")`. The terse,
however. It is three characters longer.

Something about `"timezone/America/Detroit"` bothers me. Something about
`"zones/America/Detroit"` reads better.

It is interesting to note that while I find `"timezone/America/Detroit"`
cumbersome, I do not want to rename the library itself to `"zones"`. The
library name, as it stands, is the perfect name. No room for
improvement. No desire for change.

Why doesn't the perfection of `"timezone"` carry over to the description
of timezones themselves? Perhaps what bothers me is that I'm accustomed
to reading the timezone strings themselves. `"America/Detroit"` is an
object in its own right. Perhaps it is because `"zones"` is more
indicative of a collection than `"timezone"`, so that
`"zones/America/Detroit"` looks as if `"America/Detroit"` is collected
within `"zones"`.

It does read better when it reads`"timezone/zones/America/Detroit"`.
That separates the library from the data.

There is a problem with this in that locales are also data. Although the
`"zones"` package is available on NPM, the `"locales"` package is not.
If it were available, it would seem inappropriate. Why does this one
library pertaining to time claim the more general concept of `locales`
as a package to store locale data solely for the purpose of time and date
formatting? That is bothersome.

I'd considered using `strftime` as a package name for the locales, but
that name is, of course, already taken for a JavaScript implementation
of `strftime`.

It does read better when it reads`"timezone/locales/en_UK"`, than when
it reads `"locales/en_UK"`. With `"zones"`, one can understand that this
is the timezone database itself. A logical dependency. Locales implies
that that within `"locales"` you'll find all sorts of locale
information.  I would assume that this is what "`locale`" is and inspect
the contents. I would find it presumptuous.

What reads best is `"timezone/en_UK"`.

Let's say it does. Let's say that `"zones/America/Detroit"` is far more
aesthetically pleasing, that `"timezone/America/Detroit"` is an
abomination. What do I sacrifice to go from the latter to the former?

I'd have to maintain a separate library for the timezone information. If
the library format changes, then one library might update without the
other causing breakage. There are still changes possible that would not
be exposed through the API if everything was in `"timezone"`, but would
be exposed if zones were kept in a separate package.

Not worrying about this problem will make the decision to keep
everything in one package a final decision, while the other direction
means that I'll decide later if this was a good idea.

It means I cannot say that Timezone has no dependencies. I have to say
Timezone has no dependencies other than it's own timezone database. A
slight caveat making my one liners more than one line.

It means a conceptual inconsistency if zones are kept in a separate
package by locales are not. It means a disproportionate package if
locales are kept in a separate package.

Note too,  that `z` is available. The statement
`require("z/America/Detroit")`. is both terse and pleasing. This makes
the decision even more difficult.

How often will someone have to gaze upon the abomination of
`"timezone/America/Detroit"`? When I consider use from Node.js, the most
common usage will be to include everything using
`require("timezone/everything")`.

Loading piecemeal is for the browser, so seeing individual locale names
is only for the browser. When we see them, they will be surrounded by
the bother of an async call.

I don't know how the resources will be organized, nor how they are
loaded yet. Perhaps if they are loaded relative to the library they will
be included using `"./America/Detroit"`, which is really
`"America/Detroit"`.

It occurred to me that I could return the `require` within `timezone.js`
to get a require that is shortened by relative paths, but that is so
ugly we won't mention it father.

At times I slip into thoughts of having `tz("America/Detroit")` do the
loading, synchronously using `require`, or else `tz` accepts a callback of
sorts. This is pretty for the Node.js case only and wrong in every way.

That I would even think such things shows how ugly
`"timzeone/America/Detroit"` is to me.

Which is why I'm going to have to keep it. Maybe by leaving this blemish
in, I'll find more beauty in the rest of the API. It will help me to
develop a tolerance for imperfection. Attacking it with separate package
will invite more concern and discussion, more documentation, which will
remind me of decision, although not with it's unsightly presence.

It will be out of sight, out of mind, having left a strange decision in
its place, which will require that I either describe my rationale, which
will bore the average programmer, or else fabricate a rationale, and I
despise fabricated rationales.
Merge branch `require` into `travis-ci`.