Require arm_new_za to set ZA to zero

The arm_new_za attribute creates new ZA state.  The initial contents of
this state were previously left unspecified.  In practice, there were
two cases:

1. PSTATE.ZA==0 on entry to the function.  In this case, doing an
   SMSTART ZA would clear ZA, and so the initial contents of the
   ZA state would be zero.

2. PSTATE.ZA==1 on entry to the function, due to an uncommitted
   lazy save.  In this case, the SMSTART ZA (if executed) would
   have no effect, and so without explicit action to the contrary,
   the initial contents of the ZA state could be carried over from
   the lazily-saved contents.

Case 1 is expected to be much more common than case 2.  It would
therefore be easy for code to rely (perhaps accidentally) on ZA
starting out as zero and pass testing, with case 2 only showing
up rarely, and in hard-to-debug ways.

Also, not offering a guarantee might cause code to have a defensive
zvzero_za that is executed unconditionally, even when it isn't
needed.

Finally, carrying over old contents is bad from a data isolation/
leakage point of view.

This patch therefore requires the initial contents of ZA to be zero.
Implementations can ensure this by adding a ZERO { ZA } instruction
on code paths that commit a lazy save.  Since those paths should be
rarely executed, there should be little effect on performance.

I've prototyped this in GCC and it seems to work OK.

main/acle.md

@@ -330,6 +330,10 @@ Armv8.4-A [[ARMARMv84]](#ARMARMv84). Support is added for the Dot Product intrin
   * Renamed the feature macro to `__HAVE_FUNCTION_MULTI_VERSIONING`
   * Added some clarifications.
 
+#### Changes for the next release
+
+* Added a requirement on `arm_new_za`(#arm_new_za) to set the initial
+  contents of ZA to zero.
 
 ### References
 
@@ -8805,6 +8809,8 @@ following:
     on return from the function. That is, the function does not use ZA
     to receive data from callers or to pass data back to callers.
 
+*   Every byte of the function's ZA state is initially zero.
+
 This attribute does not change a function's binary interface. If the
 function forms part of the object code's ABI, that object code function
 has a “private-ZA interface”, just like all other non-`arm_shared_za`