Decide on a hash function for `StorageSchema::commitment`

> Q: How easy is it for the registry to compute the commitment from the provided TOML file?
>
> Probably this would be some JS lib, and unless we provide the bindings (maybe we should via the web client?), there are currently three main steps in the computation:
> 1. Serialize the data without the defaults
> 2. Turn bytes into Field elements
> 3. Hash the Field elements with RPO
>
> Step 1. is rather straightforward, but 2. & 3. require Miden-specific implementations/libs. Maybe I'm exaggerating the challenge here, but it would be worthwhile to consider replacing steps 2 & 3 with a simple keccak hash (and we overflow `Word::MAX` only w.n.p. so we can still use a single word).
>
> ### Footnotes
> *the registry can be shared between the explorer and the wallet

_Originally posted by @mmagician in https://github.com/0xMiden/miden-base/pull/2244#discussion_r2689777919_

For now, we decided that we can initially ship the `SchemaCommitment` with the RPO hasher, but we may want to consider changing this to something like blake3 or keccak since they are more readily available in other environments (e.g., JS libraries), and also they are generally faster in plain CPU terms (note this is used outside of the VM).
We might also want to change how the actual commitment is performed if the plan is to make it easier to implement the storage schema commitment scheme in other languages/environments