Make Substrate Pallet Storage Abstraction Deeper

[HCastano]

The Substrate pallet provides an abstraction to its storage through the BridgeStorage trait. Right now this is a very thin wrapper around direct storage access (basically just a pass through). It would be nice to have this module provide a more rich feature set, while keeping the interface simple.

In the future different bridge pallets should be able to implement this interface and provide consistent functionality.

Related to: #296.

[tomusdrw]

Referring mostly to this comment: #409 (comment)

I think we have some misunderstanding about what "storage abstraction" is supposed to be doing.
IMO the abstraction is introduced if you don't care about specific details and you want these details to potentially be replaced by something else. Here I meant "substrate-storage abstract", where the main goal is to decouple substrate-specific storage items from the actual light client implementation.
I was pushing for this abstraction to be as low-level (as thin) as possible, cause storage reads and writes are the most expensive things we do in the runtime development, so we should really keep them at the minimal level.

It would be nice to have this module provide a more rich feature set, while keeping the interface simple.

Here I feel that you want some "abstraction" to simplify the repetitive tasks that you do in your domain-specific logic (bridge-pallet specific logic). To me this is more about extracting the common patterns into a separate, but concrete struct, if you keep the "low-level storage abstraction" minimal, you can easily build a more complex "domain storage abstraction" on top of it (for instance inserting a header and updating multiple substrate-storage values in one go), but it doesn't mean that this shared logic should be traitified, and what's more it really should not mean that we extend the minimal low-level abstraction to encompass this.
If it contains domain-specific logic (bridge-pallet specific) it's not a substrate-storage abstraction any more for me - the traits should really be minimal, it doesn't make sense to put traits everywhere where we say "abstraction", where in reality we rather mean "code simplficiation / deduplication" - this can safely go to a concrete struct that builds up on the abstract low-level storage.

[tomusdrw]

I believe this is not that relevant anymore, since we've opted for a simpler pallet-bridge-grandpa approach with only finality proofs. I feel that with BEEFY Light Client (#1223) and especially Dynamic BEEFY Bridging (#1225) we would not need to worry about storage abstraction that much.