feat(extsload): expose generic storage getter

[Rubilmax]

This solution can supplant #138 by just exposing a generic storage getter named extsload.

2 design choices were made:

1. The getter expects an array of slots instead of a single slot, because it is expected that integrators need multiple, non-contiguous storage values at once
2. There is no contiguous storage getter because for now, we don't have storage values larger than 32 bytes

If this change is accepted, I believe we should build a simple library helping integrators access the storage value they want, without thinking about the storage slots:

library BlueStorageSlots {
  function totalSupply(Id id) internal view returns (bytes32) {
    return keccak256(abi.encode(id, 5));
  }
}

Note that if we'd like to provide easy integrations, we could also provide a library for calculating accrued interests:

library BlueLib {
  function accruedInterests(IBlue blue, Id id) internal view returns (uint256 interests, uint256 feeShares) {
    // Prepare storage slot array
    // Call extsload
    // Mimick interests calculation
  }
}

But then the only advantage of doing so to have a simpler Blue contract (we don't have to separate calculation and storage update, like it's done in #138) but we force integrators to have duplicated code (interests calculation). I'm not sure this trade-off is cool for integrators...

[QGarchery]

Love it, and I agree with most points in the description in the PR. In particular, I agree that there should be a library for the slots, can you create an issue @Rubilmax ?

But then the only advantage of doing so to have a simpler Blue contract (we don't have to separate calculation and storage update, like it's done in #138) but we force integrators to have duplicated code (interests calculation). I'm not sure this trade-off is cool for integrators...

Thinking about it, it may be that integrators have potentially different use cases that cannot all be covered in the core contract. For example, they might want to know what would be the rate given that they add some borrow, and what would be the interest computation given a particular rate, etc. I agree that it comes at the cost of increase in bytecode size of the integrator contract, but it may not be significant for simple use cases, and for more complex cases they could use a similar solution to deploying a lens contract

[MerlinEgalite]

really agree with the idea, but I think we should put this PR on hold since each we'll change the storage layout the test will basically break OR we implement very general test where we randomly override the state and try to read it. Wdyt?