Intl: Add Intl.DateTimeFormat.timeZone

[kunalspathak]

Intl: Add Intl.DateTimeFormat.timeZone

This change matches the spec update section 12.3.5 of Intl's ECMA-402,
to let user specify timeZone other than UTC. Earlier, the only timeZone that can be specified in DateTimeFormat
was 'UTC'. New spec says that user should be able to specify any IANA valid timeZone. In order to make
sure that timeZone passed by user is valid, I use ChangeTimeZone() API of windows.globalization. This API returns
error if timeZone specified is invalid.
If user doesn't specify timeZone, then we should use current timeZone instead of "UTC".

This PR also includes some improvements of Intl objects initializing by delaying them. Here is the summary:

Today, we initialize and execute Intl.js code when either of the following is true.

• First time property access for below properties of Intl object :
  • Intl.DateTimeFormat
  • Intl.NumberFormat
  • Intl.Collator
• When one of below methods is called :
  • String.prototype.localeCompare
  • Number.prototype.toLocaleString
  • Date.prototype.ToLocaleString
  • Date.prototype.ToLocaleDateString
  • Date.prototype.ToLocaleTimeString

In order to execute Intl.js code, we initialize WindowsGlobalizationAdapter (WGA) objects that helps
us call into Windows.globalization.dll exported methods. Some of the WGA objects map files in memory for
easy lookup. For e.g. Objects having timeZone related methods map various files like timezones.xml,
timeZoneMapping.xml, tzres.dll.mui which increases the reference set. Although these mapped files are needed for
Intl.DateTimeFormat or Date.prototype methods, they are not needed for other APIs like String.prototype.localeCompare.
This change segregates initialization of all WGA objects we use and defers it until dependent javascript methods or properties
are called.

The WGA objects initialization falls under one of the following category:

• Common objects (needed by all the APIs)
• DateTime formatting APIs (needed by methods on Date.prototype object)
• Number formatting APIs (needed by methods on Number.prototype object)
• All of the above (needed by properties on Intl object)

(Note: String.prototype relies on common WGA objects and hence we won't initialize other objects
that are initialized for Date/Number.)

The change includes passing right flag to IntlLibraryCode telling what javascript APIs is needed and thus initializing right WGA objects.
Intl.js now takes a parameter InitType which will determine what javascript objects it should be initializing.
Also did some code refactoring.

[msftclas]

Hi @kunalspathak, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Kunal Pathak). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

[kunalspathak]

@dotnet-bot test this please.

[dilijev]

@dotnet-bot test this please

[dilijev]

@mmitche Any ideas what's going on here?

[dilijev]

@dotnet-bot test this please

[mmitche]

@dilijev Close and reopen this, it probably got caught up in the maintenance I had to do yesterday

[msftclas]

Hi @kunalspathak, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Kunal Pathak). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

[kunalspathak]

Reviewed by @Yongqu .

[dilijev]

Thanks @mmitche

[mattjohnsonpint]

Thanks @kunalspathak!

Ping here when this ships, and I'll update the ECMAScript Compatibility Chart at (under the DateTimeFormat section)