Normative: Use DefaultTimeZone to get the local time zone for Date (#2781)

Currently, it is technically possible for the following two operations to
result in different local times and different time zones:

> date = new Date()
> date.toTimeString()
'13:43:47 GMT-0700 (Pacific Daylight Time)'
> new Intl.DateTimeFormat(undefined, {timeStyle: 'full'}).format(date)
'1:43:47 p.m. Pacific Daylight Time'

This is because Date gets its notion of the current system time zone from
the operation LocalTZA, while Intl.DateTimeFormat uses the operation
DefaultTimeZone from ECMA-402 to determine the current system time zone.

This is a normative change because there was previously no requirement for
these to be linked. However, they *should* definitely be linked, and no
implementation that includes ECMA-402 that I'm aware of has a discrepancy
between the two. This patch adds this requirement.

This is accomplished by removing LocalTZA (which was actually two
operations rolled into one, anyway) and redefining the LocalTime and UTC
operations in terms of DefaultTimeZone, which moves into ECMA-262, as well
as the two new operations GetNamedTimeZoneOffsetNanoseconds and
GetNamedTimeZoneEpochNanoseconds.

It essentially pushes the "implementation-definedness" of LocalTZA into
GetNamedTimeZoneOffsetNanoseconds, GetNamedTimeZoneEpochNanoseconds, and
DefaultTimeZone.

Although it is a normative change because it adds the requirement for Date
and Intl.DateTimeFormat to use the same default time zone, it should have
no other effects. Despite specifying what LocalTZA used to do in terms of
different operations, the observable effects are the same.

Author: ptomato