Remove withTimeZone / toZonedDateTimeFormat about proposal-intl-zoneddatetimeformat

[justingrant]

Thanks Frank for opening this issue. 🙏 Here's more context about why I'd recommend not including these two methods:

The model we've followed so far in the design of Temporal is that (non-toLocaleString) Temporal APIs deal with data only while Intl and toLocaleString methods are about formatting only:

• If a developer wants to change data (date, time, time zone, or calendar) then we steer them to Temporal methods.
• If a developer wants to change how data is formatted (e.g. show or hide fields, or change how fields are displayed) then we steer them to Intl or toLocaleString.

I think there's a lot of value with keeping this distinction really clear, because it makes it easier for developers to learn when to use Temporal vs. Intl.

Also, we're already concerned that many developers are abusing Intl APIs for manipulation or parsing of data, so I don't think we want to add new APIs that make Intl APIs even easier to use for data-changing use cases.

Instead, I think we should stick with a more consistent model which is if you want to change a time zone, you use withTimeZone on the Temporal side, and you only use Intl or toLocaleString to format data that you've already set in the data model of the Temporal object.

We can't universally follow this guideline exactly because of the calendar and timeZone options for the DTF constructor that predate Temporal, but we don't need to make things worse by adding new APIs that encourage setting the time zone or calendar on the Intl side.