If the tzname is unknown, fall back to UTC for now. Unknown time zones
are most likely due to not parsing RULE entries yet, but at the very
least, it only makes sense for current_time_zone to return a time zone
that LibTimeZone actually knows about.
Instead of only having dummy functions that don't work with any input,
let's at least support one time zone: 'UTC'. This matches the basic
Temporal implementation for engines without ECMA-262, for example.
This is a rather naive implementation, but serves as a first pass at
determining the GMT offset for a time zone at a particular point in
time. This implementation ignores DST (because we are not parsing any
RULE entries yet), and ignores any offset patterns of the form "Mon>4"
or "lastSun".
This CMakeLists.txt was basically copy-pasted from LibUnicode, where the
generated data is separated into its own library. This was to let other
libraries / applications decide if they actually want to link the data
because it is so large. LibTimeZone's generated data is significantly
smaller, so this separation really isn't needed.
The IANA Time Zone Database contains data needed, at least, for various
JavaScript objects. This adds plumbing for a parser and code generator
for this data. The generated data will be made available by LibTimeZone,
much like how UCD and CLDR data is available through LibUnicode.
