…ate.

This implements requests to add a new "ZA-compatible" interface which
can be called with ZA state being either 'off', 'active' or 'dormant',
and which can preserve any and all state enabled under PSTATE.ZA.

* Renamed `compatible ZA` -> `agnostic ZA`

* Changed __arm_sme_save/restore such that the save routine should
  record whether ZA or ZT0 is saved and such that the restore routine
  should check whether ZA or ZT0 was saved. This removes the
  (previously) implicit assumption in `__arm_sme-save` that PSTATE.ZA
  must be 1 if PTR is not nullptr.

* ZA is now always saved/restored using the lazy-save mechanism.

* Changed __arm_sme_save/restore to have a custom ZA interface instead
  of 'agnostic-ZA' which was incorrect.

As @rsandifo-arm explained, the same routines cannot be used for
general use of saving/restoring of state enabled by PSTATE.ZA
because of the different expectations on the ZA interface
when partially saving/restoring state enabled by PSTATE.ZA.

Removing the option, drastically simplifies the logic. Note that
I have removed the two booleans (internal to the save/restore
routines) that distinguish between having saved 'ZA' and 'ZT0',
and replaced that with a single 'VALID' bit, because I think we
can assume that the save/restore routines are called by PEs that
have the same SME state.

This changes the 'dormant on entry' case to be 'no change'.