Improve timezone support

[mikee47]

This PR fills some gaps in Sming's support of time zones.

Time zones are a complex issue and best left to a separate library.
However, some minimal changes are required to the framework itself.

Fixes

• Remove DT_DATE_SEPARATOR - no longer used

• Add MINS_PER_HOUR definition

• Don't restrict SystemClock timezone offset range. Can vary much more than plus/minus 12 hours.

• Make core DateTime defines signed. Causes all sorts of hidden issues performing arithmetic otherwise.

• Ensure DateTime:: fromHttpDate(), fromISO8601() and setTime() set weekday correctly.
  Requires full conversion to/from time_t, so add static versions of these methods which can also be used where broken-down time isn't required.
  Any failure in parsing means the DateTime value is left unchanged, rather than in an indeterminate state.

Add Zoned Time support

This uses DateTime::ZoneInfo and ZonedTime to provide a basic mechanism for dealing with zoned time information.
Handling rules, etc. must be handled with separate library.

ZoneInfo provides information associated with a point-in-time
ZonedTime contains a UTC timestamp (time_t) plus ZoneInfo

This naming is common amongst other libraries, e.g. java.

DateTime formatting now supports "z", ":z" and "%Z" format specifiers with provided (optional) ZoneInfo parameter.

Handle transitions to/from daylight savings

Adds a callback to the SystemClock so that the timezone offset can be maintained efficiently.
Update SystemClock_NTP sample and add to Windows CI builds.

Obtaining the local time involves converting the current system clock time from UTC using an offset based on the currently active timezone rules. The Timezone library is one way to deal with this, but not the only way of course.

There is currently no mechanism for keeping the system clock time offset correct, other than periodically setting it. For example, this is how the SystemClock_NTP sample currently does it. However, that's not ideal since we might only need to update via NTP infrequently; the two tasks aren't actually related.

This is the code added to the SystemClock_NTP sample, in the NtpClientDemo.cpp file:

void checkTimeZoneOffset(time_t systemTime)
{
	static time_t nextChange;
	static const TimeChangeRule* rule;

	if(!rule) {
		tz.toLocal(systemTime, &rule);
	} else if(systemTime < nextChange) {
                // For most calls we just return
		return;
	}

        // This happens on first call, or if switching from DST to STD or vice-versa (twice a year!)
	SystemClock.setTimeZoneOffset(rule->offset * SECS_PER_MIN);
	nextChange = tz.getNextChange(systemTime, &rule);
}

It's important to note that the system clock must be correctly set before this is called for the first time.
Therefore the call to SystemClock.onCheckTimeZoneOffset(checkTimeZoneOffset) is made only after setting the clock in our NTP callback. From then on, checkTimeZoneOffset is called whenever the local time is requested from SystemClock.

It's efficient because we note when the next change to/from DST is and so only need to check it, but will guarantee that the correct local time is returned without having to perform a full TimeChangeRule calculation every time.

NOTE: This isn't a perfect solution since there are ways to easily bypass the update check. Something the user might want to add into their applications is a periodic manual check, perhap?

Timezone library changes

Add POSIX timezone string support

Adds support for parsing POSIX timezone definition strings.

C library support for timezone generally involves code like this:

setenv("TZ", "CET-1CEST,M3.5.0,M10.5.0/3");
tzset();

This approach is complex and inflexible so the code has been ported from newlib so that rules can be easily defined using these strings.

Provide standard timezone rule definitions

A set of timezone data can be built directly from the IANA database information.
This is limited to the standard POSIX string definitions.

The data itself is deliberately NOT included in the library as it changes frequently, sometimes several times a year.

Note: Whilst currently this data is generated statically for linking with applications,
future improvements to the library will consider mechanisms for keeping this information updated in a running system,
without having to re-flash the firmware.

Testing

Add extensive testing to validate generated rules and compare against OS-provided transition tables.

TODO:

• Review timezone offset update mechanism
• Review documentation
• Review how timezone data is incorporated into applications; consider whether it's the right initial approach