Introduce AccountId version wrapper

[PhilippGackstatter]

The changes in this PR are:

• Introduce AccountId version wrapper for AccountId and AccountIdPrefix. Both seemed necessary since prefix is also specific to V0.
• Refactor AccountIdVersion from a struct into an enum as it makes it possible to exhaustively match on all versions.
• Move AccountType, AccountStorageMode and AccountIdVersion to separate modules. Nothing was changed about these, so the code doesn't have to be reviewed again.

This approach should generally allow to introduce another AccountIdV1 without breaking APIs, except if:

• its byte format is not [u8; 15]. This seems like something we at least won't increase since that would break the metadata encoding.
• If we add a new AccountType or AccountStorageMode in the future it would be breaking. A wrapper for these doesn't seem quite right though. We could simply make AccountStorageMode and AccountType non-exhaustive, so at least the API would not be broken if we add new variants. However, that obviously breaks exhaustive matching which is very nice to have. And perhaps it's okay if these kinds of additions are a breaking change on the API level.

Should the inner version's methods be publicly exposed or should we make them private? Some code may want to work with a specific ID version so it seems best to keep them public.

Some deduplication of documentation would be nice. Perhaps the V0 methods should point to the wrapper methods unless they're different (like if we have a new version in the future), e.g. on AccountIdV0:

/// See [`AccountId::account_type`].
pub const fn account_type(&self) -> AccountType { ... }

part of #1046.

[bobbinth]

Looks good! Thank you! I left some comments inline - most are minor. Once these are addressed, we can merge.

its byte format is not [u8; 15]. This seems like something we at least won't increase since that would break the metadata encoding.

Yes, I think we can assume that IDs will remain 15 bytes in the foreseeable future.

• If we add a new AccountType or AccountStorageMode in the future it would be breaking. A wrapper for these doesn't seem quite right though. We could simply make AccountStorageMode and AccountType non-exhaustive, so at least the API would not be broken if we add new variants. However, that obviously breaks exhaustive matching which is very nice to have. And perhaps it's okay if these kinds of additions are a breaking change on the API level.

I would keep them exhaustive.

Should the inner version's methods be publicly exposed or should we make them private? Some code may want to work with a specific ID version so it seems best to keep them public.

Yes, I think that's fine.

Some deduplication of documentation would be nice. Perhaps the V0 methods should point to the wrapper methods unless they're different (like if we have a new version in the future), e.g. on AccountIdV0:

/// See [`AccountId::account_type`].
pub const fn account_type(&self) -> AccountType { ... }

I'm fine with this - though some of the comments I left are about making sure that these types of references leading to the actual docs (rather than another reference).

[bobbinth]

The documentation of account ID just refers us to docs of specific versions. Should we refer to specific versions here and avoid this extra potential "hop"?

[PhilippGackstatter]

Good point, thanks for pointing this out.

I resolved it by moving the main account ID documentation to AccountId directly. If we add another version in the future, it will most likely differ only in some details, so we can document this directly on that type instead of duplicating everything on a AccountIdV1 type.
That way, these comments pointing to the AccountId type still lead to the actual docs so I left them mostly as-is.