Zone offset formatting.

I'm developing a far more substantiative offset lookup function for a subsequent
commit. The updates to `convertToPOSIX` and `convertToWallclock` in this commit
are stop along the way. They will do the right thing for a couple of key clock
transitions in `America/Detroit`. This allows us to test the zone offset and
timezone abbreviation formatting.

Zone Offset Formatting
----------------------

I've implemented the `%z` and `%Z` format specifiers, including the precision
specification using the colon `:`. Tests accompany the implementation.

The zone entry and rule entry are now cached in the `request` context object for
use in the zone offset formatting functions.

For some reason I find it notable that the formatting functions now accept a 4th
parameter, that only the `%z` implementation function uses. That is the string
of matched colons for the `%z` specifier for the colon separated variants, e.g.
`%::z`.

Olson File to JSON Preprocessor - Savings Letters
-------------------------------------------------

To simplify formatting the zone abbreviations, the Olson file to JSON
preprocessor program has been updated to replace a rule entry's `letter`
property value with with `""` if it is `"-"`. This way we don't have to convert
from `"-"` to `""` in our formatting code. It is merely a shift of this
conditional from the `tz` function into the Olson file to JSON preprocessor.

Olson File to JSON Preprocessor - Modularization
------------------------------------------------

The Olson file to JSON preprocessor program now prepends the `module.exports`
assignment before the JSON string. Not sure why it wasn't doing that before.
Maybe I had a plan to load those files without using `require`.

In fact, how do I imagine I'm going to load those files in the browser? They
would be of no use to a browser as simple JSON, since they must load
synchronously. I know I didn't leave this project in October of last year
thinking that zones and locales were going to load through callbacks.

I'll cross that bridge when I create the `gh-pages` demos. Premature
cross-platform considerations are like premature optimization, at least in the
case when something is known to be generally cross-platform.

On premature optimization, I've always felt it better to say premature
micro-optimization is the root of all evil, so that it maintains the spirit of
the original quote, when taken out of context.

> Programmers waste enormous amounts of time thinking about, or worrying about,
> the speed of noncritical parts of their programs, and these attempts at
> efficiency actually have a strong negative impact when debugging and
> maintenance are considered. We should forget about small efficiencies, say
> about 97% of the time: premature optimization is the root of all evil. Yet we
> should not pass up our opportunities in that critical 3%.

Snipped that quote from [c2.com](http://c2.com/cgi/wiki?PrematureOptimization).

If you are going to find the longest common sequences in two series, you need a
difference algorithm. It is not premature optimization to forgo a naive attempt
at a difference using nested for loops.

Similarly, I'm finding that if I write for Node.js first and only, but it just
so happens that I have few dependencies, then it turns out that library was a
browser-also library after all. (This probably could be better said in the log
messages for [Strata](http://github.com/bigeasy/strata).)

As a result of these updates to the JSON output files, I've updated all of the
zone JSON files.

All Timezones Module
--------------------

For the Node.js require mechanism, I created an index that will load all
timezone JSON files in the timezone directory and create a single export.

Clock Transition Observations
-----------------------------

Timezone offset calculation is going to be replaced shortly, but these are some
notes on the current implementation.

There are lots of interesting edges in the file.

 * The start of standard is always a to the second offset, based on the relation
   of the sun to a particular municipality.
 * There US Peace Time, a transition that is only an abbreviation transition,
   that is triggered by a UTC time.
 * Standard times have been discovered in the European files, so a time in the
   Olson files indicate clock transitions using either UTC, standard or
   wallclock time.
 * There is the implicit first rule before the first daylight savings time rule
   that has savings. It implies no savings. To be sure that I'm using the
   correct letter in the entry format, I search for an example of no savings,
   using a subsequent rule entry as a placeholder for the implicit one.

Why We Never Parse Timezone Abbreviations
-----------------------------------------

I'd considered what it meant to go the other way, to parse timezone offsets.

The numeric offsets can and will be parsed. The timezone abbreviations cannot be
parsed. Something that I'd considered in the past with the same conclusion.
Something I'll consider in the future with the same conclusion.

Recently, I rediscovered one of my favorite comments from the Olson files...

>	The UNIX Version 7 "timezone" function is not present in this package; it's
>	impossible to reliably map timezone's arguments (a "minutes west of GMT" value
>	and a "daylight saving time in effect" flag) to a time zone abbreviation, and
>	we refuse to guess.

I'm sure I'll ponder whether I'm supposed to support this again at some point in
the future, but in my notes for this commit, I have out of scope written in all
caps. It seems that, when I think about it for a while, I'm angry at the notion
of being responsible for such a thing. I'm succumbing to admonishment-oriented
programming, where I imagine someone pestering me in a comment somewhere about a
possible implementation.

Parsing timezone abbreviations is natural language processing. We don't do that
in this library.

Tidy
----

Renamed the variable `epoch` to `posix` in `t/offset/dst`.