Return version, change clock, return internals.

Changes to the calling conventions for the **Timezone** function.

With invocation, any argument that **Timezone** cannot interpret is
ignored. If you specify a date string that **Timezone** cannot parse, it
will discard the date string, since it doesn't know if it is, in fact, a
poorly formed RFC 3999 date. It could be a format where the caller
forgot to include a format specifier, or the name of a time zone rule
set that has not been loaded.

When the **Timezone** function is invoked with no arguments, it returns
a version string.

If the first argument is an array and the first element in that array is
numeric, then it is interpreted as a date array.

If the first argument is a number or an object that will convert to a
number, that number is used as POSIX time.

If the first argument parses as an RFC 3999 date the parsed value is
used as the date.

If the first argument is the string `"*"`, the clock value is used for
the current date.

If any argument contains a `%`, that argument is a format. The last
format specified wins.

If any argument is a locale name determined by its pattern, that is a
candidate for the locale to apply, last locale specified wins. If there
is no data for the named locale, then the string is discarded.

If any argument can be parsed as a date math operation, the date math
operation will be applied to the date value. Date math operations are
applied in order. At this point, adjustments are not included in partial
functions.

Otherwise, if the argument is a string and it did not match anything
above, we'll assume that it is the name of a time zone rule set. If no
such time zone rule set exists, then it is ignored.

Arrays that are not interpreted date arrays are flattened into the
variable arguments.

Any function is called with the request as the `this` context. It the
function returns a non-null value, then the **Timezone** function
returns that value immediately. These functions can be used to set the
clock or add format specifiers. They can also be used to inspect the
context, with a debugging function. (Maybe pass the date?)

If the object has a name property, then it is interpreted as a locale
definition.

If the object has a zones property, then it is interpreted as a zone
rule set definition.

Everything defaults to the inherited context. This is new. Before I was
resetting the locale to "en_US" if the specified locale was undefined.
It should revert to the inherited locale.

If no date can be found, a partial function is created from the given
request.

Removed the `retry` array, instead writing the candidate zone to a local
variable, and assigning it to the request if it exists outsize of the
arguments loop.

Previously, both the zone name and the date were defaults, but we have a
simple test to see if something is potentially a date, that excludes the
possibility that it is a zone name.

The clever notion to pass the **Timezone** function itself as the first
argument to indicate now was too clever and caused to much bloat. It
presents problems when the **Timezone** function is encapsulated in
another function. If the caller wants to specify now to enclosing
function, it cannot, because it does not have a handle to the
**Timezone** function itself.

    File                             Raw         Min         Zip     Min/Zip
    timezone.js              14745/14.40  7600/07.42  4042/03.95  2931/02.86
Date arrays begin with `"@"`.

To reduce ambiguity between an array of zone or locale definitions and a
date array, the first element of a date array is now the character
`"@"`, the sigil for a Perl array, because I once spent a lot of time
with Perl.

This reduction in ambiguity means that the **Timezone** function will
flatten any argument array. An argument list can be built in an array
and given directly to the **Timezone** function, without having to
invoke `Function.apply`.

Given that the crux of the **Timezone** API is specified is the
arguments array, this optional invocation method will probably prove to
be more than a nice to have.

    File                             Raw         Min         Zip     Min/Zip
    timezone.js              14722/14.38  7584/07.41  4040/03.95  2930/02.86
Return partial if date fails.

Was feeling that it was important to go right ahead and ignore a date
that does not parse correctly, or an array date that resolves to `NaN`,
but as I commit the change, I'm having a change of heart.

Why not make a best effort to validate the users data? If they provide a
string that begins with a number, then it must be a date. If it doesn't
parse, then we ought to throw an exception. It is not a recoverable
exception, but it will aid in debugging.

I'm retreating because I need to find a way to report an RFC 3999 date
string that given a time zone detects that the time does not exist in
the time zone. Return NaN? Well, what if there is a date format?

An exception is the only reasonable response. Perhaps returning NaN if
there is no format, but raising an exception if there is one?

In any case, now that date array is unambiguous, the intent of the
caller is clear. It makes more sense to raise an exception if the
contents are not numeric, than to return a partial.

    File                             Raw         Min         Zip     Min/Zip
    timezone.js              14855/14.51  7679/07.50  4074/03.98  2954/02.88
Unambiguous zone rule sets.

Previously, the test to see if a member of the context was a zone rule
set was to test if the member was an array. Zones are arrays, but so are
the daylight savings time rules. To resolve this ambiguity, the zone
rule set arrays now have the string `"z"` as their first element.

    File                             Raw         Min         Zip     Min/Zip
    timezone.js              14855/14.51  7675/07.50  4078/03.98  2959/02.89
Thorough validation.

This is thorough validation of arguments, adding over a kilobyte in size
to the library. It now teeters on the brink of 3k.

What this represents is a departure from the simplicity of the one
function interface, to something of a janky domain-specific language.
The introduction of the `"@"` to the date array to reduce ambiguity is
actually the introduction of types. The exceptions are type checking.

If that is what you want, then make a `TimeZoneConverter` object, name
the functions, and throw all kinds of exceptions.

The whole thing is off in the wrong direction, but I'm going to create a
release, so I can look at might have been. Also, it mapped out all the
different failure paths, so I'd like to continue to build off that.

    File                             Raw         Min         Zip     Min/Zip
    timezone.js              15320/14.96  7944/07.76  4214/04.12  3050/02.98

Closes #57.
Closes #54.
Closes #62.
Merge branch `validating` into `master`.