Solidity address <> Miden AccountId helper functions

[partylikeits1983]

This PR implements conversion functions for Solidity address type (bytes20) to Miden AccountId & Address.

Concretely what functionality does this PR add?

This PR adds Rust conversion functions to convert AccountId into solidity address type and back. Additionally there is a masm procedure to convert the address type represented as [5; Felt] (part of CLAIM note inputs) into AccountId. TLDR; part of bridging EVM<>Miden

NOTE:
This PR does not assume it possible to represent any arbitrary Ethereum address as an AccountId.

This PR adds functions to be able to represent an AccountId as an Ethereum address (20 byte hex string) and adds conversion functions which can take this very specific ethereum address which represents an AccountId and convert it back to AccountId.

Why?

Because to bridge from EVM to Miden, a user will call the bridgeAsset() function on an EVM chain. The destination address on Miden will be this ethereum address which represents an AccountId on Miden.

---

Builds on top of #2188

Added Rust helper functions:

• account_id_to_ethereum_address_hex: AccountId -> Solidity address type
• ethereum_address_hex_to_account_id: Solidity address type to AccountId
• ethereum_address_to_felts: Solidity address type to address[5] (part of CLAIM note inputs)

MASM helper procedures:

• hashing a address[5] type with keccak256 (might not be necessary, but this was a first test before implementing Implement getLeafValue() in MASM #2220)

• converting address[5] type into an AccountId type

Resolves: #2229

[bobbinth]

Looks good! Thank you. I left some more comments inline.

[mmagician]

I think there is a discrepancy between u32 and u64 usage.
IIUC, the changes in this PR propose a representation of the address such that the first element is zero, and the rest are u64s (w/o overflowing the max field size).

However, for hashing the elements with keccak, which is needed as part of #2220, we need all elements to fit inside u32s. And then we necessarily need all 5 u32s to be non-zeros to represent 160 bytes of the Ethereum address.

Let me know if this makes sense or whether I'm missing some context.

[igamigo]

Still getting familiar with some of this code but leaving a couple of comments

[partylikeits1983]

@mmagician @igamigo

I clarified the byte/u32-limb/64-bit word representations in doc comments (and aligned Rust limb ordering with MASM), added explicit “no mod-reduction” checks when constructing felts from 64-bit words, and switched the AccountId -> EthAddress conversion to From<AccountId> since it’s infallible.

I also simplified the ethereum_address_to_account_id procedure

[mmagician]

Unless I'm missing something, I have the same comment as before: this needs a rather fundamental rework still, because it is not possible to represent 20 non-zero bytes corresponding to an Ethereum address with 4 u32s (i.e. 128 bits), so the PR is conceptually incorrect.

[mmagician]

Looks good, with some small outstanding comments re: naming, efficiency and function structuring.
It would be good to still align on the naming & structure before merging, but otherwise ✅

[bobbinth]

Looks good! Thank you! I left some more comments inline. Once these are addresses, we should be good to go (but also would be good to get @mmagician's sign-off).

[bobbinth]

For some reason, I had previously thought that Ethereum addresses are natively in little-endian order - but it seems like they are in big-endian order. So, does this mean that to get the address in this form we need to reverse the bytes?

If so, it may be worth going back to the "native" order of Ethereum addresses - i.e., addr0 = bytes[0..3].