1.0: Remove lfs64 API (open64 and similar)

With 1.0 we will default to 64-bit time_t and off_t, and users will need to opt in to 32-bit versions of these APIs - if we expose them at all. This means the API like open64 will be redundant with open. There isn't a reason to use both unless a user opts in to 32-bit off_t but occasionally needs to use 64-bit operations: this doesn't sound like a usecase worth supporting. They also aren't posix.

To back this up, it sounds like musl would deprecate them if they could.

-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE have nothing to do with supporting large files properly but with exposing the idiotic legacy interfaces with 64 on the end of their names (like open64, lseek64, etc.). only -D_FILE_OFFSET_BITS=64 should ever be used, anywhere, even on glibc.

Clarifying what exactly I think we should do here: I don't think we should deprecate just yet. libc is going to go through stages that users are going to follow:

64-bit off_t/time_t is not universally present on 32-bit platforms
64-bit off_t/time_t is available behind an unstable cfg (we're pretty much here now)
64-bit off_t/time_t is available behind a stable cfg
1.0, only 64-bit off_t/time_t on all platforms by default

If we start deprecating API before users have a stable cfg, that seems extremely likely to cause user confusion because if you're using code like this:

#[cfg(env = "glibc", bits = "32")]
use libc::open64 as open;

and would like to start testing with libc_unstable_gnu_time_bits = "64", then how do you avoid deprecation warnings while getting the correct behavior? If you import libc::open then your library may stop working if libc_unstable_gnu_time_bits is unset. If you cfg your import on libc_unstable_gnu_time_bits = "64", you're going to get surprised when that cfg gets renamed to something without _unstable. The fact of the matter is that seeing a name like open64 currently means you know that you are 64-bit safe regardless of platform, and I don't want to start making that ambiguous without a clear path forward.

So, what to do:

At this time I think we should identify everything we want to deprecate without actually deprecating it yet. E.g.:

// FIXME(1.0,deprecate): lfs64 binding to be removed
fn open64(...);

That way we can still get things in piecemeal without flipping the switch just yet. Once we're past step 3 we can easily find+replace to actually deprecate them, and right before step 4 we delete everything that's deprecated.

To be clear: this mostly refers to targets where we need some form of config that can be toggled. If open64 never existed on the platform then I'm a bit more open to deprecating now on less popular targets, though this is still going to be case-by-case because I'd still like it if users only need to update their imports once. With dependencies in the tens of thousands, little bits of churn add up :)

aix: annotate most lfs routines for deprecation