Prepare for modularization.

Grouped functions into future modules. The `transitions` function now accepts
the data object as its first parameter. Some variables in the global namespace
were moved into the scope that defines transition. The `en_US` object of arrays
has become `ABBREV`.

Slightly smaller.

    File                             Raw         Min         Zip     Min/Zip
    forward.js               17244/16.84  9128/08.91  5034/04.92  3487/03.41
Split `transitions.js` out of `forward.js`.

Finding the transitions is now in a separate module, so that it can be used by
both the 7-bit ASCII encoder and the JSON encoder.

    File                             Raw         Min         Zip     Min/Zip
    forward.js                7990/07.80  5003/04.89  2477/02.42  1984/01.94
    transitions.js            9261/09.04  4160/04.06  2843/02.78  1731/01.69
Pull `7-bit.js`, `display.js` from `forward.js`.

Extracted the 7-bit ASCII encoding into `7-bit.js`. Extracted the display of the
clock transitions and zone record seams to `display.js`.

The `7-bits.js` and `forward.js` programs will continue to verify their encoding
after encoding by decoding after encoding and comparing the decoded table with
the original table.

The `display.js` program is used to verify that the output of `transitions.js`
is correct, by creating a plain text listing of all clock transitions that can
be compared against the output of GNU `date`, as we've been doing with the
`verify` program.

    File                             Raw         Min         Zip     Min/Zip
    forward.js                2702/02.64  1541/01.50  1007/00.98   812/00.79
    transitions.js            9261/09.04  4160/04.06  2843/02.78  1731/01.69
    7-bit.js                  4555/04.45  2849/02.78  1591/01.55  1282/01.25
    display.js                1431/01.40   774/00.76   645/00.63   482/00.47
    timezones/asia.js      131087/128.01 60231/58.82  7420/07.25  6351/06.20
Redo zone record preprocessing.

Moving away from having legible JSON in the Olson as JSON files, starting with
the zone records. Instead of an ISO 8601 string from the until property, it's
seconds since the epoch. Using `false` for the maximum zone record, instead of
just leaving the property out of the record. This is because I intend to move to
arrays instead of objects for zone records.

Converted the silly `utc` and `standard` booleans to a `clock` property. This is
going to be single integer to save us the quote characters before we're done.

Converting the offset to seconds since the epoch. No savings in JSON size
because, for the most part, the offsets are specified in six characters as
strings.

I'm only going to commit the changes to `tz2json.coffee` and `transitions.js`
for now. I'll commit the changes to the Olson as JSON files in one final commit
before merging this branch back into the `tabular` branch.

I'll be using `asia.js` as a measure of progress toward a smaller Olson as JSON
file format.

    File                             Raw         Min         Zip     Min/Zip
    timezones/asia.js      130174/127.12 58705/57.33  7520/07.34  6482/06.33

Notice how the raw and minified JSON is shrinking, but the zipped and minified
and zipped JSON is growing.

Date strings might be more efficient than seconds since the epoch. At some point,
we may look to using the `tz` function itself to parse the Olson to JSON files.
Any time we're messing around with these files, the `tz` function will be close
by. Invoking it is not verbose.

Date are an option if they compress better.
Redo rule record preprocessing.

Setting the clock in the conversion and removing its detection from
actualization. Adding the clock increased the size of the Olson as JSON file.

Removed the unused `type` property.

Converted `time` to minutes. Simplifies `actualize` slightly. It is almost
always the top of an hour in the first few hours of the day, so it can't be any
less repetitive than the strings.

Converted `save` to minutes. Savings in the raw file size of `transitions.js`,
but no savings, none at all, after minify and gzip. Saved 17 bytes in the Olson
as JSON file.

Converted `rules` to minutes When `rules` is a savings. Thereafter, I was able
to remove `parseOffset` from `transitions.js` saving 114 bytes minified and
gzipped.

    File                             Raw         Min         Zip     Min/Zip
    transitions.js            7692/07.51  3418/03.34  2392/02.34  1449/01.42
    timezones/asia.js      130742/127.68 59273/57.88  7535/07.36  6429/06.28
Add time to actualized rule in one place.

Removed the optional `clock` parameter from `setClocks`. Never used.

Change to `actualize` so that it determines the date using one of the three
methods for determining date first, then adds the time of day to the calculated
date, as opposed to working the day and date portion of a full date when
calculating the date.

Also, `actualize` assigns the value of the wall-clock without using a switch
statement.  Previously, the switch statement would try to build a more actuate
notion of a POSIX time date by attempting to apply the current timezone offset,
which would be incorrect, but close enough. Now that I have a fixture, I can see
that there are no instances where mixing POSIX time dates with wall-clock and
standard time dates causes the rules to be sorted incorrectly.

In fact, I can now determine the two closest clock transitions, which would give
me some confidence in this particular fudge factor, ordering rule transitions by
date, instead of by actual time. Opened #16 to create a program that will verify
our assumptions about rule records.

    File                             Raw         Min         Zip     Min/Zip
    transitions.js            7147/06.98  3171/03.10  2279/02.23  1376/01.34
Sort precompiler files into directories.

Moved the new precompiler files split out from `forward.js` to the `lib` and
`bin` directories. Going forward we'll update `7-bit.js` with any further
changes to `transitions.js`. If we ever decide that the 7-bit ASCII encoding is
the way to go, we'll have ready and waiting. There's no real need, at this
juncture, to delete the file.

    File                             Raw         Min         Zip     Min/Zip
    lib/transitions.js        7147/06.98  3171/03.10  2279/02.23  1376/01.34
    bin/7-bit.js              4562/04.46  2856/02.79  1595/01.56  1286/01.26
    bin/forward.js            2708/02.64  1547/01.51  1010/00.99   816/00.80
    bin/display.js            1445/01.41   788/00.77   647/00.63   486/00.47
Use `Date` to calculate last date of month.

Occurred to me that I could use the JavaScript `Date` object to calculate the
last day of the month. This eliminates two functions and a lookup table from
`lib/transitions.js`. Removing logic is the only sure way to shrink the size of
minified and gzipped JavaScript.

    File                             Raw         Min         Zip     Min/Zip
    lib/transitions.js        6782/06.62  3063/02.99  2148/02.10  1313/01.28
No longer going backwards.

Deleted `adjustments.coffee`. No longer going backwards. Certainly can't go
backwards through the Olson files as they are. They would need to be converted
into a format that permits going backwards.

Maybe at some point in the future I'll once again consider a format that
calculates as needed. It would be the only way to get the size of the rule set
tables smaller, to eliminate entries.

Offhand, with all that I know now, I can say that it would be possible to
convert the transitions to wall-clock time within each zone record, for a
particular zone. The problem with walking backwards was calculating wall-clock
time given a potpourri of rules. If our precompiler converts those rules to
wall-clock for us, then we can scan backwards. We need for all the times to be
set to the same clock for a zone entry.

Our precompiler could add to a zone, only those rules that are applicable, not
the full set of rules. It can adjust the rules to simplify their selection. I
did learn from `adjustments.coffee` that rules are sorted by `from`, but for
traveling backwards through them they need to be sorted by `to`.

That is another deep dive, should I ever choose to dive into this problem again.

We will have rule actualization in `tz` anyway, to actualize rules for future
dates. If we can build a backwards scan using that actualization code, then
we've paid for the compress JSON rule set tables already.

If it does require a significantly larger `tz`, it is a dubious savings. It is
important that `tz` itself be small, so it can be adopted for timezone ignorant
uses. To grow it in order save some bytes in the JSON rule set tables is not a
good trade-off. Slightly smaller JSON rule set tables are unlikely to unlock a
whole new initialization pattern.
No longer storing data in GitHub.

Not sure where I want to store the generated files, so I'm deleting the ones
that I've stored. I'll have to update the `Cakefile` to build the necessary
files, for development and publishing.

Considering usage. Don't want to have initialization of `tz` have to require
long, ugly paths. I'm considering taking over the `zone` or `zones` namespace in
NPM, but having just considered it, I can't decide between `zone` and `zones`.
When requesting a specific rule set, `zone` seems appropriate.

    var detroit = tz(require("zone/America/Detroit"));
    var europe = tz(require("zone/Europe"));

When requesting a groups of rule sets, `zones` seems apropriate.

    var detroit = tz(require("zones/America/Detroit"));
    var europe = tz(require("zones/Europe"));

Still no bright ideas for hosting zones for the browser. Wringing my hands over
potential MITM attacks when hosting using GitHub pages.
Created Timezone Database downloading Makefile.

Created a Makefile that will

 * download the Timzeone Database from IANA, along with the code,
 * build the reference `zic` compiler,
 * compile `zoneinfo` files.

This gives us `zic` compiled `zoneinfo` files based on the same data we us to
create our JSON rule set tables. We use these files with our `bin/verify`
program. Out `bin/verify` program uses these `zoneinfo` files with GNU `date` to
verify that the `lib/transitions.js` library can correctly determine all of the
clock transitions in the Olson files. We will not encounter errors because the
`zoneinfo` our out of date or otherwise different from the IANA Timezone
Database on the machine we're using for testing.

The Makefile will also

 * build our Olson as JSON files,
 * build of JSON rule set tables,
 * copy the load everything `index.js` into the timezones directory,
 * and copy a load everything `index.js` into each of the sub-directories in the
   `zones` directory including the `zones` directory.

The `index.js` files that load everything are kept under `lib/indices` for now.
One for the Olson as JSON files, named `lib/indices/timezones.js` that will load
every Olson as JSON file, all the continents. One for the JSON rule set table
files named `lib/indices/zones.js` that loads every rule set table in the
current directory and its sub-directories. When these are copied into place by
the `Makefile`, they are renamed `index.js`.

    // Load all JSON as Olson files.
    var world = require("timezone/timezones');
    // Load the JSON as Olson file for Asia.
    var asia = require("timezone/timezones/asia');

    // Load all JSON rule set tables for the Americas.
    var americas = require("timezone/zones/America");
    // Load all JSON rule set tables for Indiana.
    var indiana = require("timezone/zones/America/Indiana");
    // Load the JSON rule set for Vilnius.
    var vilnius = require("zone/Europe/Vilnius");

Considering using the `zones` NPM namespace for the zone files. Sadly, `tz` is
taken, because I'd like to have that option to consider. Although, when I do
consider it, I like keeping use the name `tz` as the name of our do-it-all
function, by convention, and using `zone` or `zones` for data, which would help
resolve ambiguity.

Occurs to me, and there is no where to put this, but any application that is
only interested in current time, not historic time, say an application that
shows you the real time of your flight, might want to download only the last
five years of rules. Perhaps this saves someone some bandwidth.

Although I've not written a nicely formatted test that will decorate my Travis
CI output, I am verifying against the `zic` compiled IANA Timezone Database, so
this commit closes #12. I've created a new issue, #17, to add package this
verification for reporting by the `proof` test runner.
Merge branch `precompilation` into `tabular`.

This merge of the `precompilation` branch successfully sidelines the 7-bit ASCII
rule set table compiler and closes #13.