Define soft-float PCS for AArch64

With the release of the Cortex-R82, we now have an AArch64 CPU which can
be built without any floating-point instructions or registers, so I
think we should re-consider our decision to not have a soft-float
variant of the AArch64 PCS.

I've worded this as a variant over the base PCS, to keep it simple.

No compiler implements this yet, but clang does already allow passing
floating-point types without an FPU, and seems to implement the first
bullet point correctly. I'm working on LLVM patches which will
implement bullet points 2 and 3.

GCC doesn't currently allow any use of floating-point types without an
FPU for AArch64, so we don't need to worry about compatibility with
existing code there.

For the fourth bullet point, I don't think we need to define the PCS for
vector types, because these are only defined by the ACLE when the
relevant hardware exists.

aapcs64/aapcs64.rst

@@ -253,6 +253,7 @@ changes to the content of the document for that release.
 |            | October 2023       |                                                                  |
 +------------+--------------------+------------------------------------------------------------------+
 |            |                    | - Change the status of the SME support from Alpha to Beta.       |
+|            |                    | - Add soft-float PCS variant.                                    |
 +------------+--------------------+------------------------------------------------------------------+
 
 References
@@ -2028,6 +2029,21 @@ size\_t, ptrdiff\_t
 
 See `Arm C and C++ language mappings`_.
 
+Soft-float
+----------
+
+The soft-float variant is defined for Arm v8-R implementations that do not have floating-point instructions or registers. This variant is incompatible with the base procedure call standard and toolchains are not required to support it.
+
+The soft-float variant is defined identically to the base variant, with these changes:
+
+* All floating-point types are passed as if they are an Integral machine type with the same byte-size and alignment.
+
+* No types are considered to be HFAs or HVAs.
+
+* The definition of ``va_list`` is unchanged. The ``__vr_top`` and ``__vr_offs`` fields may be left uninitialised by ``va_start``, and their values must not be relied on by ``va_arg``.
+
+* The calling convention for Short Vector, Scalable Vector and Scalable Predicate machine types is left undefined.
+
 .. raw:: pdf
 
    PageBreak