Use musl's strptime implementation

[sbc100]

This is a slight regression in code size compared the JS version, but makes the wasm file more standalone and portable. I measured the combined size of
core2.test_strptime_days (with closure compiler enabled) and got the
following results, which is a 2% regression:

• before: 16777 bytes
• after: 17235 bytes

As part of this I updated musl's implementation to support several
features that our current tests depend on:

• Add support for '%z' for parsing timezone offsets.
• Add support for '%U' and '%W' (week of the year)
• Derive and set tm_yday/tm_mday/tm_yday fields where possible.

Regarding '%U' and '%W' it seems this is missing from both musl and
bionic:

• https://github.com/aosp-mirror/platform_bionic/blob/4cfb2bde90fcf0a1f835e2b670b00e9f226c1c7c/libc/tzcode/strptime.c#L364-L375
• https://github.com/bminor/musl/blob/f314e133929b6379eccc632bef32eaebb66a7335/src/time/strptime.c#L126-L132

However, I implemented here (based on code from FreeBSD) in order to
avoid any regressions (since we do have test coverage for these flags).

Fixes: #21024

[kripken]

This seems to save on code size compared the JS version [..] I measured the combined size of core2.test_strptime_days (with closure compiler enabled) and got the following results:

before: 16777 bytes after: 17235 bytes

That looks like a regression, not a savings, or are the two sentences talking about different things?

[sbc100]

This seems to save on code size compared the JS version [..] I measured the combined size of core2.test_strptime_days (with closure compiler enabled) and got the following results: before: 16777 bytes after: 17235 bytes

That looks like a regression, not a savings, or are the two sentences talking about different things?

Yeah sorry, it was a saving, but then once I added all that new code (the stuff that musl doesn't implement) it grew by a little and now its a slight regression., but its only 2%.