utmp 64 bit time_t support

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

The gnulib developers has reported that the lack of 64-bit support on utmp
records has created some real issues [1]. This issue is problematic because
now some 32-bit architectures when built with 64-bit time_t support have
a different utmp struct size, which essentially breaks __WORDSIZE_TIME64_COMPAT32
support. The simple straightforward fix would to make utmp/utmpx always 32-bit
for theses architecture (mips, mips64n32, riscv32, sparcv9, and i686) but this 
would be an ABI break.

Thorsten has summarized other issues with the interface [2], and it is even a 
problem for some 64 bit architectures that define __WORDSIZE_TIME64_COMPAT32 
(mips64, powerpc64, riscv64, sparc64, and x86_64) [3][4].

The current implementation also has a security issues [5] that would require a
complete rewrite to move the functionality to a proper service (which poses its
own issues).

Thorsten suggestion would to replace wtmp with journald, which would require
some code rewrite since is has a different ABI. But I think this is the best
way to fix it.

I have sent a possible 64 bit fix [6], but as Joseph has hinted there is not
easy way to maintain compatibility [7].  It would require a lot of work, 
probably some breakage; which I think no one is really interested in fixing.

So I think it is really time to just deprecate these functions, move them to 
compat symbols, and return ENOSYS for new code.

Thoughts?

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30701
[2] https://github.com/thkukuk/utmpx/blob/main/Y2038.md
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=28146
[4] https://sourceware.org/bugzilla/show_bug.cgi?id=17470
[5] https://sourceware.org/bugzilla/show_bug.cgi?id=24492
[6] https://sourceware.org/pipermail/libc-alpha/2020-July/116742.html
[7] https://sourceware.org/pipermail/libc-alpha/2020-July/116764.html