Heuristics assertions.

Created a program to report the smallest interval between meaningful changes in
timezone offset or timezone abbreviation. The shortest interval is 6.125 days in
`Asia/Yerevan`. This confirms that we can sort transitions by an actualized
date, and that if we're off by some combination of timezone offset and daylight
savings time, we don't muddle the order of events.

When we order rules, we're not always able to calculate the exact time for each
of our clocks, wall-clock, standard and POSIX, because it depends on the rules
in effect, that is, the timezone offset plus any daylight savings. We need to
know what rules came before the current rule. To do this we sort the rules, but
we don't know exact times, because we're unsure of offset and savings. Thus, we
sort by date, instead of by date and time.

These tests show that we can indeed sort by date and obtain the order in which
daylight savings time rules are applied.

Closes #16.
`lib/transitions.js` no longer fixes up.

Moved the fixup of the zone records in `lib/transactions.js` to
`bin/tz2json.js`. `bin/tz2json.js` now emits the records in the order that
`lib/transactions.js` expects.
Working skip list.

With a few slight changes to the JSON as Olson format, it is possible to walk
backward through the Olson database.

The problem with walking backwards with the records as they are lies with the
different clocks. Most transitions are specified in wall-clock time , but some
are specified in POSIX time, while others a specified in standard time.

If we are searching for a clock transition in POSIX time, we need to convert
from POSIX to wall-clock. The clock transitions indicate the time when the clock
transition occurs. To convert from one clock to another, we need to know the
timezone offset and daylight savings in effect at the time of clock transition.

That means that in order convert one clock transition, we need to know offset
and savings applied by the previous clock transitions. Very frequently, the
previous clock transition is ambiguous, because zone records will often trump
rule records, so to be sure that a rule record is not trumped by zone record,
we'll need to know the exact time for zone records and rule records. To know the
exact time, we'll need to know the offset and savings of the clock transition
before each of them, meaning we need to keep walking backward, in order to walk
forward, so that we can walk backward.

Much easier to walk forward. We always know the offset and savings in effect.
We're changing the clock as we go forward through time, following the design of
the files, and modeling the real world.

It is simple enough to convert the zone record to backward instead of forward.
Each zone record only occurs once, so its wall-clock time and POSIX time can be
calculated. These records are unique.

The rule records are shared between zone rule sets, however. Rule records
indicate a clock transition that occurs on a certain day of the year for a range
of years. The actual day is calculated. So, some locale may set their clocks
back on the last Sunday of November throughout the 1980s, which means ten clock
transitions are generated. Maybe two cities use the same daylight savings time
rules, but with different timezones offsets, so that's twenty records created.

This is why we care about walking backward. It would be nice if we only had that
one rule record and we could calculate the rest by walking backward. But, as we
just explained, we won't know the time of a rule, without knowing the offset and
savings applied by the rule before.

However, the values of savings do not vary much. People are, for the most part,
setting their clocks forward a bit, then back to zero, where a bit is a number
that doesn't change for a rule set. People set their clocks forward an hour, or
twenty minutes, but whatever the number, it doesn't change from year to year.

That means that a rule to set the clocks back to zero is preceded by a rule that
sets the clock forward the same amount. It may be different rules, but it is
almost always the same amount.

With this in mind, we can walk forward through the Olson database and build our
table of every clock transition, the one we use with a binary search to find a
clock transition. However, we now keep track of the rule record or zone record
that was used to calculate the clock transition.

We can now move through the table and assert that every clock transition
generated by a rule is preceded by a clock transition that applies the same
value for savings. We build all the tables for all the zone names, then we
perform this check across all the zone names. We need to only assert that the
savings in effect is the same each time the rule is applied, not the zone
offset. We know the zone offset of a rule set as we walk it.

This works. Almost all of the rules in the database are converted into clock
transitions that begin with the same savings in effect. There are a handful of
cases where the savings in effect varies. When the savings varies for a rule for
a particular year, we split the rule, so that there is a rule specifically for
that year. A range of rules is not divided into two or three ranges, with one
range being for a specific year. This makes it so that the savings in effect is
consistent for every rule.

Now all the rules can have a new property, `saved` that indicates the daylight
savings time in effect when the rule is applied.

This in turn means that we can move backwards through the file, because for each
rule we know both the timezone offset, specified by the zone entry that
requested the rules, and the daylight savings time when the rule comes into
effect, so now we can convert from POSIX to wall-clock at each rule record,
without having to go back in time to determine the effective daylight savings.

Our final product will be a pre-compiler that converts form the Olson files to
our Olson as JSON format. Then we'll walk forward through the Olson as JSON to
create our clock transition tables annotated with the zone and rule records that
created them.  We'll use these table to rewrite our rule records. We generate
skip lists from the annotations. We can then verify that the skip lists work
using tables, checking that the skip lists can find each clock transition,
before and after.

The output is the skip list, which is the format used for all zone tables,
including the great big ones. If you load `America/Detroit.js`, you get the
`Detroit` rules. If you subsequently load `America.js`, you get them again. The
specific locality files are simply the subset that contains only what's needed.

We're not going to make an attempt to further prune the rule arrays included, to
only the rule records needed, even though you keep thinking about it. (Stop it.)

In future commits, we're going to eliminate standard time rules, by converting
them to wall-clock. We need to assert that no standard time rule plus its
effective savings is greater than 24:00, which is the case at the time of
writing. This will simplify our skip list code, because it will only have to
convert between two clocks, POSIX and wall-clock, instead of three clocks when
standard is included.

This commit is is horrendous, full of debugging messages. It is at the time of
after the last edit before we were able to visit all the clock transitions and
successfully detect them in POSIX time using the skip list.

Next we're going to see if we can successfully detect the correct settings for
the millisecond before clock transitions in POSIX time.
Test millisecond before transition, fix MIN_VALUE.

`Number.MIN_VALUE` is the [smallest positive numeric value representable by
JavaScript](https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Number/MAX_VALUE)
, not the smallest negative value. The smallest negative value is
`-Number.MAX_VALUE`.

Added an initial record to the skip list for the timezone abbreviation before
the adoption of standard time.

The find function can now find the correct offset and savings for the
millisecond before a clock transition.

The find function was failing for dates that fell on the new year. For
`America/Detroit`, the shift from `Detroit` rules to `US` rules at New Year's
1975 cased the `applicable` function to skip the fall back date in October 1974.

Rather than continue to fiddle with the date math to get the correct current
year for wall-clock specified year ranges for a POSIX time, I decided to use a
range of three years, including the two years surrounding the year indicated by
the POSIX time. It creates a larger a set of applicable intervals which we may
seek to prune in time, but for now it gets us to a working algorithm that we can
optimize later with tests in place, and all searches correctly implemented.
Now correclty finding wallclock time.

Exclude rules that are younger than the start of the current zone entry record
according to the clock used to specify the rule.

Surprised this is not breaking because standard time is not available in the
zone entry record. Dumb luck. We're going to try to translate standard time to
rules to wall-clock time, so hopefully this will not be an issue.
Skip list in `lib/timezone.js`.

The skip list method of determining zone offset and abbreviation has now
replaced the binary search in `lib/timezone.js`. `lib/timezone.js` is now much
fatter than it has been, with a bloaty implementation of everything involved.

The new zone offset and abbreviation lookup requires that the abbreviations are
generated from the formats. This logic will always be larger than the clock
transition table's implementation, since the formatted abbreviations were part
of the lookup table.

The offset in the entry record no longer includes the daylight savings.

Created `bin/zones.js` to export the skip list to the `zones` directory,
replacing our sorted tables of clock transitions with the skip lists in the zone
files for each locality. The function `lib/transitions.js` now returns an object
containing both the clock transitions table and the skip list. The clock
transitions table is still used for assertions about our heuristics, and to
generate our file containing all the clock transitions that we use to test our
parser against GNU `date`.

A squish of all this code will come in a separate working branch, possibly after
another release, certainly after adding the GNU extension for user specified
padding extensions. Allow the code to expand a little, while you assert that the
skip list is working and that the implementation of `strftime` is complete.

    File                             Raw         Min         Zip     Min/Zip
    lib/timezone.js          13328/13.02  6243/06.10  3929/03.84  2721/02.66
    lib/transitions.js       12769/12.47  5799/05.66  3381/03.30  2207/02.16
    date.js                   4515/04.41  3090/03.02  1200/01.17  1007/00.98
    timezones/asia.js      156900/153.22 76694/74.90  8713/08.51  7343/07.17
    zones/America/Detroit.js  2994/02.92  2483/02.42   560/00.55   546/00.53

The size of `lib/transitions.js` doesn't matter anymore. We're never going to
expose this to an application now. It is only a utility to generate the files.
Putting in the report one last time as a bookend.

Closes #21.
Test globbed zone loading.

Created a test to ensure that loading a zone directory loads all of the zone
files in that directory tree. It also ensure that loading a zone directory loads
only the zone files in that zone directory's directory tree.
Merge branch `skip-list` into `master`.