Consider making `hash_string_to_word` a `const fn`

`hash_string_to_word` essentially, blake3-hashes its input and converts the result into a `Word`.

The `blake3` crate doesn't offer a `const` implementation, afaict, but there is https://github.com/triblespace/const-BLAKE3 as an alternative. We may want to look into that to enable deriving hashes in `const` contexts.
I think the main question is how trustworthy the implementation is.

This would be useful in miden-base to bring back `StorageSlotName::from_static_str`, which is no longer possible now that we have included the derived `StorageSlotId` into the slot name itself.

Instead of defining slot names like this:

```rust
static FALCON_PUBKEY_SLOT_NAME: LazyLock = LazyLock::new(|| {
StorageSlotName::new("miden::standards::auth::rpo_falcon512::public_key")
.expect("storage slot name should be valid")
});

impl AuthRpoFalcon512 {
pub fn public_key_slot() -> &'static StorageSlotName {
&FALCON_PUBKEY_SLOT_NAME
}
}
```

It would allow us to guarantee compile-time slot name validation and expose a nicer API for users:

```rust
impl AuthRpoFalcon512 {
pub const FALCON_PUBKEY_SLOT: StorageSlotName = StorageSlotName::from_static_str(
"miden::standards::auth::rpo_falcon512::public_key"
);
}
```

Look at the `hash_string_to_word` function in the codebase, likely in a hashing or utils module. Investigate the `const-BLAKE3` crate as an alternative to the current `blake3` crate for const compatibility. The goal is to enable `StorageSlotName::from_static_str` to be a const function again, allowing compile-time validation. Check the existing tests for `hash_string_to_word` and `StorageSlotName` to understand the expected behavior.

由索引模型根据 Issue 内容生成。