Investigate embedding signature scheme type into public key commitments

Currently, we compute public key commitments by reducing a public key to a sequence of field elements and then computing their sequential hash (i.e. via the `SequentialCommit` trait).

Public key commitments are important because this is how MASM procedure signatures work in the Miden core lib (e.g., `ecdsa_k256_keccak::verify` takes a public key commitment as an input). Inside these verification procedures, we verify that the commitment matches a public key provided via the advice provider, and then run signature verification.

This setup works well as long as public key commitments map uniquely to signature schemes. This is currently the case, but in the future we may introduce other schemes that may result in collisions. For example:

- If we were to introduce Bitcoin-style ECDSA that uses SHA256 instead of Keccak for hashing, the keys for `ecdsa_k256_keccak` and `ecdsa_k256_sha256` would be the same.
- If we were to introduce the canonical version of Flacon, we'd have the same issue as the public key would collide with our Poseidon2 version of Falcon (@Al-Kindi-0 correct me if this is not so).

A solution could be to "fiddle" with the public key commitment to embed signature scheme information into it. For example, we could overwrite 5 - 8 bits of the commitment with signature scheme enum (we are unlikely to have more than a dozen or two signature schemes - even in the longer run).

I think the main consequence of this would be that signature verification procedures in `miden-vm` core lib would need to take this fiddling into account and ignore these bits when comparing the provided commitment with the computed one.