Store selectors mapping in pool implementation storage

[gabririgo]

Summary

Store the selector to adapter address mapping in the pool implementation storage to remove moving parts of the protocol.

Motivation

The biggest downside of implementing an extendable but non-upgradable-extensions flow is that we will very often find ourselves in situations where pools having different implementations will behave differently with external applications. The biggest perk of the current design is that while the core protocol maintains the same APIs across versions and is not expected to change much across versions, the extensions will change as we add and remove support for external applications, therefore having governance-upgradable extensions guarantees all pools use the latest extensions. This is particularly relevant in case of bugs in external applications, where a prompt governance response can safeguard smart pools' assets, with the guarantees of the Rigoblock governance.

Specification

TBD.

Rationale

Storing the mapping in the implementation would save the initial 2100 gas required to warm up the authority contract. It would also remove the extensions as a moving component, thus allowing extending the protocol in a modular and gas-efficient. Lastly, it would allow deprecating the authority contract entirely, thus enabling upgrades only when a pool operator upgrades.

Notes

TBD.