Drop workarounds for Android API levels pre 9, 17, 21.

The minimum Android API currently supported by the LTS NDK is 21.

Check that the function has at least one parameter before trying
to access its type.

Fixes https://github.com/llvm/llvm-project/issues/148770.

It should not be possible to construct one without a triple. It would
also be nice to delete TargetLibraryInfoWrapperPass, but that is more
difficult.

While pvalloc() is a legacy POSIX function, it remains widely available
in common C libraries like glibc.

Model pvalloc() in TargetLibraryInfo, allowing LLVM to correctly infer
its attributes.

This patch adds support for the `libmvec` vector library on AArch64
targets. Currently, all `libmvec` functions in GLIBC version 2.40 are
supported. The full list of math functions enabled can be found
[here](https://github.com/bminor/glibc/blob/96abd59bf2a11ddd4e7ccaac840ec13c0b62d3ba/sysdeps/aarch64/fpu/Versions)
(up to GLIBC 2.40).

Previously, `libmvec` was only supported on x86_64 targets. Attempts to
use it on AArch64 resulted in the following error from Clang:
`unsupported option 'libmvec' for target 'aarch64'`.

Fixes #138787

To the best of my knowledge, DXIL does not (and should not) support any
of the libcalls in
[`TargetLibraryInfo.def`](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Analysis/TargetLibraryInfo.def).
Math libcalls are not used in HLSL and also do not have lowerings to
DXIL. (The current implementation of math functions are done via
intrinsics.)
If there is a mistake with disabling all libcalls, then the libcalls we
need can be re-enabled in a follow-up PR.

---------

Co-authored-by: Justin Bogner <mail@justinbogner.com>

Renames LIBMVEC-X86 to LIBMVEC and updates TLI to only add the existing
x86 specific mapping when targeting x86.

- Do not call pass initialization from pass constructors.
- Instead, pass initialization should happen in the `initializeAnalysis`
function.
- https://github.com/llvm/llvm-project/issues/111767

Some ArmPL vector math routines that operate on fixed-width
vector types obey the aarch64_vector_pcs calling convention,
e.g. armpl_vsinq_f64, etc. This patch adds support for
functions in the TLI to specify an optional calling
convention to be added to the declared function. Once this
patch lands I intend to follow up with a vectoriser patch
that adds this optional calling convention when invoking the
vector library variant from the loop vectoriser.