`glibc>=2.34` (RHEL 9) integration of `libpthread`, `libdl`, `libutil`, `libanl` into `libc`

### Comment:

In today's conda-forge/core meeting the question came up whether we'd need any changes regarding `libpthread`s' (et al.) integration into `libc` itself for `glibc>=2.34` (used in RHEL 9 onward).

In contrast to `libcrypt.so.1`'s removal (in RHEL 9 onward and generally in future `glibc>=3.29` releases) for which we do have to make changes (see gh-52), we probably don't here since backwards compatibility is given.
See upstream changelog:
https://sourceware.org/git/?p=glibc.git;a=blame;f=NEWS;hb=refs/tags/glibc-2.34#l12 :
> * In order to support smoother in-place-upgrades and to simplify
the implementation of the runtime all functionality formerly
implemented in the libraries libpthread, libdl, libutil, libanl has
been integrated into libc. New applications do not need to link with
-lpthread, -ldl, -lutil, -lanl anymore. For backwards compatibility,
empty static archives libpthread.a, libdl.a, libutil.a, libanl.a are
provided, so that the linker options keep working. Applications which
have been linked against glibc 2.33 or earlier continue to load the
corresponding shared objects (which are now empty). The integration
of those libraries into libc means that additional symbols become
available by default. This can cause applications that contain weak
references to take unexpected code paths that would only have been
used in previous glibc versions when e.g. preloading libpthread.so.0,
potentially exposing application bugs.

Opening this issue here so we are at least aware of the changes and can track potential adjustments.

@chenghlee, if you have encountered cases for which this change causes issues, do let us know!