storage(substore): add delimiter handling

[erwanor]

According to the ICS24 spec, substore prefixes are identifiers. This means that they "MUST" follow precise requirements:

An Identifier is a bytestring used as a key for an object stored in state, such as a connection, channel, or light client.

Identifiers MUST be non-empty (of positive integer length).

Identifiers MUST consist of characters in one of the following categories only:

Alphanumeric
., _, +, -, #
[, ], <, >

This means that our decision to include a trailing delimiter for our IBC prefix is technically incompatible with the spec. This is unfortunate, because it greatly simplifies the routing logic. However, in practice this could become a problem if a counterparty IBC implementation decides to enforce this requirement.

This PR adds support for removing delimiters from our defined prefixes. Instead of defining an ibc/ prefix, the user defines a prefix identifier "ibc". The routing logic handles adding/stripping a delimiter "/". For example, a key path: ibc/path/to/client/state will result in a match to the ibc substore at key path/to/client/state.

However, quietly managing delimiters adds some complexity. Naively, we could find ourselves in a situation where we collisions occur e.g. "ibcpath/to/client/state" and ibc/path/to/client/state. Similarly, we now have extra edge cases to enforce that we never write an empty key to a substore: ibc, ibc/ would resolve to the same key.

To avoid this, we only route a key to a substore if it contains a prefix, a delimiter, and a non-empty substore path e.g. "ibc/path/to" and "ibc/key" routes to the "ibc" substore, but "ibc/" and "ibc" don't.

[erwanor]

I'll change our StateWrite trait to forbid inserting empty keys in a future PR.

[avahowell]

LGTM