PoS - refactor the crate's API about namada HOT 2 CLOSED

The approach to this will be to use trait StorageRead introduced in #324 (with some related follow-up PRs, currently included in draft #352) to provide a simpler read queries interface at PoS specific RPC paths.

This is because with the raw PoS data, to e.g. find a staking power of a validator or delegator, one must read from multiple storage values (slashes and reward products), so it's much better if that's handled on the ledger's side before returning back to client, instead of the client having to query the raw storage value multiple times.

from namada.

I'm switching this to high priority as it will help with code re-use (in e.g. our client, governance which needs to know voting power of validators and delegators for proposal tallying), other integrations wanting to query PoS state such as namada-interface. It will also help with PoS development for which we need to do many breaking changes to the storage layout and types, but can and should be hidden from PoS state consumers by such RPC interface.

from namada.