Fix issue 12507. This makes SysTime.init equivalent to SysTime(0, UTC())...

....

SysTime.init was supposed to be equivalent to SysTime(0, LocalTime()),
but at the time std.datetime was written, it wasn't possible to initialize
member variables which are classes at compile time. It has since become
possible to initialize them if they're immutable (which TimeZone always
is), but LocalTime still can't be used in that context, because it has
have tzset called when it's initialized (otherwise, the C timezone
functions aren't properly set up). However, UTC _can_ be used in that
context, because it doesn't use any C functions (its conversion
functions do basically nothing as they're converting from UTC to UTC).
So, if we use UTC as the timezone for SysTime.init, we can have a valid
SysTime.init.

This isn't completely ideal, because SysTime normally defaults to LocalTime
if you don't give it a timezone, but since the only alternative that I'm
aware of is to make it so that SysTime's functions check timezone for null
whenever it's used (and use LocalTime instead if it is), which would add
constant overhead just to make SysTime.init valid, I think that this is a
good compromise. It makes SysTime.init valid without adding overhead.

So, this should fix all of the existing problems with SysTime.init,
including the fact that toString doesn't work for it (which is issue#
12507).