See also D154945. It took me a while to track down the source of the
problems with the existing patterns.

Tablegen patterns for instrucion selection can generate multiple
instructions, but only if there is a data dependency between them so
that they can be expressed as a DAG. For example, something like:

(store (load %src), %dst)
For some patterns, we might want to generate a sequence of instructions
which do not have a data dependency. For example on AArch64 some atomic
instructions are implemented like this:

LDP %ptr
DMB ISH
Currently, sequences like this can not be selected with tablegen
patterns. To work around this we need to do custom selection, which has
several disadvantages compared to using patterns, such as needing
separate implementations for SelectionDAG and GlobalISel.

This patch adds basic support for tablegen Patterns which have a list
of output instructions. Pattern already has the ability to express this
but it looks like it was never implemented.

Multiple result instructions in an output pattern will be chained
together.

The GlobalISel pattern importer will skip these patterns for now. I
intend to implement this soon.

Change-Id: I3ac2e64b86233dd4c8b4f7f6effa50ed29759f25

This commit is a follow-up to 99a562b3cb17e89273ba0fe77129f2fb17a19381,
which migrated some of the mlir-vulkan-runner tests to mlir-cpu-runner
using a new pipeline and set of wrappers. That commit could not migrate
all the tests, because the existing calling conventions/ABIs for kernel
arguments generated by GPUToLLVMConversionPass were not a good fit for
the Vulkan runtime. This commit fixes this and migrates the remaining
tests. With this commit, mlir-vulkan-runner and many related components
are now unused, and they will be removed in a later commit (see #73457).

The old calling conventions require both the caller (host LLVM code) and
callee (device code) to have compile-time knowledge of the precise
argument types. This works for CUDA, ROCm and SYCL, where there is a
C-like calling convention agreed between the host and device code, and
the runtime passes through arguments as raw data without comprehension.
For Vulkan, however, the interface declared by the shader/kernel is in a
more abstract form, so the device code has indirect access to the
argument data, and the runtime must process the arguments to set up and
bind appropriately-sized buffer descriptors.

This commit introduces a new calling convention option to meet the
Vulkan runtime's needs. It lowers memref arguments to {void*, size_t}
pairs, which can be trivially interpreted by the runtime without it
needing to know the original argument types. Unlike the stopgap measure
in the previous commit, this system can support memrefs of various ranks
and element types, which unblocked migrating the remaining tests.

Ref.: https://cdrdv2.intel.com/v1/dl/getContent/828965

SVE2.2 introduces instructions with predicated forms with zeroing of
the inactive lanes. This allows in some cases to save a `movprfx` or
a `mov` instruction when emitting code for `_x` or `_z` variants of
intrinsics.

This patch adds support for emitting the zeroing forms of certain
`SCVTF`, and `UCVTF` instructions.