fix: deprecate/fix time_t family types under Windows x86 GNU on stable

[dybucc]

Description

Under Windows GNU x86, time_t doesn't have the right size and alignment. This is a
backwards-incompatible change, so for folks to experiment on stable, a cfg has been exposed to
allow exposing a 64-bit time_t instead. Tests don't fail because we still skip time_t and
records containing some value of such type whenever we're under this target platform/environment.

In #5059, we address the issue with routines involving time_t values by making them link to their
32-bit symbols on that platform/environment.

This should allow not breaking existing code (even though incorrect,) while still allowing new code
to experiment with correct size/alignment for time_t values. The cfg tries to follow the new
practices introduced in #4977.

An additional job was not added to the test matrix in CI because it was instead introduced as part
of the tests in ci/run.sh that run only under 32-bit machine word and GNU-hosted targets.

Sources

None, if any the same as #5032 as this stems from it.

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.