Configuration via partial functions.

Implemented the partial generation API that I invented while writing the
`gh-pages` documentation. Now configuration is a matter of generating a partial
`tz` function by calling `tz` with parameters, but no date. In this case, `tz`
creates a closure around its conversion function that will add the enclosed
parameters to parameters passed into the closure, before calling the conversion
function.

The conversion function accepts as its first parameter a context object that
holds onto parameters that are too complicated to merge on each call; i.e. the
zones and locales. The parameters that are not too complicated to merge are
prepended to the parameters provided by the user. This allows the user to
override parameters enclosed in a partial function, because for parameters that
are not cumulative, the last parameter wins.

You'll notice that we track the start of passed-in parameters, since the date,
if any, is going to be the first passed-in parameter.

Changed the signature of conversion functions. Locale is looked up once and
passed into each function as before, but the timezone is left within the request
object, which is passed in as a last parameter. The request parameter is only
needed when a format uses `tz` itself to apply a canned format. When `tz` is
used to with a format that does not reference locale specific data, we can call
`tz`. When a format might need the locale, we call `convert` directly, using the
request for the context object. Our nested call to `convert` will then use all
of the same locale and timezone data for its format.

Somewhat slower, but I've managed to bring back some initially discouraging lost
performance. The hit came when I removed branches that short-circuited timezone
conversion when then timezone was UTC. Looked fussy.

I put it back. If UTC is timezone, we do not convert between `posix` and
`wallclock`. I put this short-circuit in the conversion functions themselves. It
is more performant to perform the test before I call the conversion functions,
but this means that I won't once again forget and tidy this optimization away in
some future change set down the road.

I'm better able to admit that I'm fallible. It is admonishment-oriented
programming to sweat whether you're going to be chastised for performance or
chastised for the inevitable bug that comes from when you once again see the
test for the UTC timezone sprinkled throughout the code, and cull the code
assuming that you where in a rush and left yourself with spaghetti to untangle.
It is obvious that you're short-circuiting an unnecessary calculation when it is
a `return` statement at the start of a function. You'll leave that be.

It is admonishment-oriented programming to sweat the balance between code size
and code speed. You're tipping the scales at 4.6k minified and zipped, so you're
not eager to unroll logic, short-circuiting before every call.

There are always admonishments. Simply find someone who is too immature to
understand that compromise is inherent in software, sit back, and watch them
stamp their feed and demand excellence. Speed versus size is a classic
trade-off, and you're always open to admonishments about the deficiencies that
come from making a commitment to one metric over another.

Don't be a shoulda, coulda, woulda programmer. Someone who begins every
discussion of their work by heading off the criticisms. Talk about what you did,
not what you didn't.

Performance can be seen in the long running tests for week of year with 14640
assertions each. A follow up to this commit would be to recreate one of the week
of year tests within the test program, implementing its operations in the test
program. Comparing the run times of this test against its analogous test that
uses Timezone would give us a sense of the cost of the API cladding.

Note that I changed the variables named `utc` to `posix` to bring the code into
line with the documentation. The function `convertToUTC` is now
`convertToPOSIX`.