`<chrono>`: Investigate whether we can rework definition of `zoned_time` constructor

[mnatsuhara]

The Standard defines zoned_time's constructor with recursive constraints. We currently mirror the Standard's definition in our implementation, but we should investigate whether it's possibly to implement them non-recursively.

Examples: zoned_time(string_view{}) https://github.com/microsoft/STL/blob/65eb5077778a11cc4abac88b5fd5d0a25a2dcd19/stl/inc/chrono#L2980-L2984

zoned_time(string_view, const sys_time)) https://github.com/microsoft/STL/blob/65eb5077778a11cc4abac88b5fd5d0a25a2dcd19/stl/inc/chrono#L2993-L2998

[frederick-vs-ja]

These constructors are inconsistently constrained.

• For the default constructor, it's merely constrained on traits::default_zone() being well-formed, but there's no requirement that traits::default_zone() can be used to initialize TimeZonePtr.
• For the constructor from one string_view, the constraint says traits​::​locate_zone(string_view{}), but zone_ is then initialized with traits​::​locate_zone(name), where the value categories of the arguments of locate_zone are different.
• For other constructors that are "equivalent to" construction with {traits​::​locate_zone(name), ...}, the implicit constraints essentially require traits​::​locate_zone(name) to be convertible to TimeZonePtr.

Furtherly,

• in many constructors, it's unclear whether "initialize" means "direct-non-list-initialize". The differences between direct-initialization and direct-list-initialization are observable.

(Currently MSVC STL consistently uses direct-list-initialization.)

Edit: Oops, these functions can cause infinite meta-recursion if traits::locate_zone returns a string_view, and zoned_time(string_view) is really inconsistent.

Edit: Filed LWG-4067.