refactor: deprecate off64_t in VxWorks

[dybucc]

Description

As a follow up to #5127, this deprecates the same type on VxWorks. This continues the trend towards supporting a single 64-bit wide type for time and file offset values, instead of having suffixed variants (see more on that in the afore mentioned PR.) VxWorks does short work of it, because off_t is already defined with that bit-width.

While looking through the VxWorks headers, though, I noticed they support a 32-bit off_t whenever the system is not operating in user-land (with what they refer to as RTPs or Real Time Processes.) I can't include any sources because it's part of the downloadable SDK, but maybe this is worth considering. As per the GNU docs [1], the macro they check for to determine which definition should be made available is exposed when the -mrtp flag is issued during compilation. I haven't considered how would we detect this from the Rust side of things, though, or if we even want to.

Something else I wanted to note was that the VxWorks module seems to define functions that are not part of the VxWorks interface (based on the fact they're not declared within an extern block, and on both the comment that precedes them and the abasence of them in the downloadable SDK.) These use the suffixed variant of the off_t type, so I've had to annotate them with an allow(deprecated). Reading through the Linux manpage for those two routines, it may be that VxWorks has some register passing issues when running under x32, but that's just a personal hypothesis from the text and not something explicitly mentioned. It'd be great to get some outside input on this, as I'm not sure why we just reutrn the return value corresponding with an error, without attempting to also set errno (considering we pull the errno Rust crate and we're manually implementing these routines, this seems reasonable.)

Sources

• Lines 23-26 of b_off_t.h under sysroot/usr/h/public/base in the VxWorks downloadable SDK for QEMU x86_64.

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

[dybucc]

CI actually passes. There seems to be an issue with a glob import that is not used, but this has not
been changed in the patch (it's not even part of it, for that matter.) For some reason, rebasing
onto main with dependabot updates has ended up with a warning across all of my open PRs due to
that one (now apparently unused) import.

[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.