refactor: deprecate *NUM constants fitting #3131

[dybucc]

Description

Constants matching the *NUM naming scheme whose purpose is that of denoting a limit among
other symbols have been deprecated in this patch. This stems from the deprecation efforts in #3131.

This is a follow up PR to #5120.

Sources

• The WCTYPE_ALNUM constant in the TEEOS tree has not been deprecated because I could not find the
  symbol in the OpenHarmony SDK. I tried with all versions of the latest SDK as released in both
  their GitHub and their Gitee, but I had no luck after running rg with the following command.

  rg -C 10 -S -g "*.h" -e "WCTYPE_ALNUM"

• The PT_NUM in the Fuchsia source constant has not been deprecated because it does not seem to be
  used as a limit of any sort.

  https://cs.opensource.google/search?q=pt_num&sq=&ss=fuchsia%2Ffuchsia:zircon%2F

• The AT_PHNUM constant in NetBSD, FreeBSD, Android and Linux/L4RE has not been deprecated as the
  accompanying comments mention they are supposed to denote some number of entries, which I assume
  as not implying the type of "limit" value we're looking to deprecate.

  https://github.com/search?q=repo%3ANetBSD%2Fsrc%20AT_PHNUM&type=code

  https://github.com/search?q=repo%3Afreebsd%2Ffreebsd-src%20AT_PHNUM&type=code

  https://github.com/search?q=repo%3Atorvalds%2Flinux%20at_phnum&type=code

  https://cs.android.com/search?q=at_phnum&sq=&ss=android%2Fplatform%2Fsuperproject

• The VFS_MAXTYPENUM FreeBSD constant has not been deprecated because it does not seem to be used
  as a the type of "limit" value we've deprecated in related PRs.

  https://github.com/search?q=repo%3Afreebsd%2Ffreebsd-src+VFS_MAXTYPENUM&type=code

• The B_DEV_BAD_DRIVE_NUM constant under the Haiku tree has not been deprecated as it seems to
  just be another enum variant among a few other constants denoting errors.

  https://github.com/search?q=repo%3Ahaiku%2Fhaiku%20B_DEV_BAD_DRIVE_NUM&type=code

• The ELFCLASSNUM and EV_NUM Linux and L4RE constant have been deprecated as the context in
  which they are used in the upstream codebase and the fact they are trailing constants after two
  other symbols, implies they're the type of "limit" values we would want to deprecate.

  https://github.com/search?q=repo%3Atorvalds%2Flinux%20ELFCLASSNUM&type=code

  https://github.com/torvalds/linux/blob/f5e5d3509bffb95c6648eb9795f7f236852ae62d/include/uapi/linux/elf.h#L380

• The ELFDATANUM Linux and L4RE constant has not been deprecated because I could not find it in
  neither one of the Linux nor L4RE upstream repos (neither kernels.)

• The ET_NUM and PT_NUM constants in Linux and L4RE have not been deprecated because I could not
  find them in neither one of the Linux nor L4RE repos.

  https://github.com/torvalds/linux/blob/f5e5d3509bffb95c6648eb9795f7f236852ae62d/include/uapi/linux/elf.h#L72

  https://github.com/search?q=repo%3AL4Re%2Ffiasco%20%2F%5B%5E%5B%3Aalpha%3A%5D%5Det_num%2F&type=code

  https://github.com/search?q=repo%3Atorvalds%2Flinux+PT_NUM+path%3A%2F%5Einclude%5C%2F%2F&type=code

  https://github.com/search?q=repo%3AL4Re%2Ffiasco+pt_num&type=code

• The ED_INVALID_RECNUM constant in the GNU Hurd was not deprecated as the comment alongside its
  declaration does seem to imply it's not the type of "limit" value we're looking to depreacte.

  https://cgit.git.savannah.gnu.org/cgit/hurd/glibc.git/tree/sysdeps/mach/hurd/bits/errno.h?h=t/sysvshm#n407

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]

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.