[Protocol Specs] Clarify how signing extensions are meant to be implemented

[nlordell]

Currently the protocol specs have this comment:

There are continuous efforts to expand the types of signatures supported by the EVM beyond the currently predominant secp256k1 elliptic curve. For example, a signature scheme gaining popularity is based on the secp256r1 elliptic curve (see EIP-7212). Signature Validators allow accounts to support new standards and enable use-cases such as Passkeys-enabled smart accounts, BLS/Schnorr or quantum-secure signatures.

However, it is unclear exactly how this fits into the current signature validation specification (which is very much geared towards EIP-712 and EIP-1271).

Questions

• There are solutions involving ERC-1271 "account" contracts, but this would be protocol adjacent - do we insist on having signing extensions be part of the protocol or part of the account implementation?
• Using the account's ERC-1271 signature support, we could potentially make it work by setting the SignatureManager contract as an owner. This would require some consideration on "can an owner's signature count more than once?" and "how do multiple owners use an extension for signing". This would allow for a protocol-centric approach to extending Safes with new signing schemes, but doesn't seem like a clean approach.
• Are these signing schemes intended to be universal (i.e. apply to transaction signing, ERC-4337 user operation validation, and ERC-1271 signature verification)?