Refactor Storage Access to be 4337 Compatible

[nlordell]

This PR changes the manager storage to use the account in the inner most mapping. This allows the Manager to be used with 4337 during signature validation. Note that tests continue to pass.

I also noticed that most storage is public with an addition direct accessor function. This generates additional code (for example, it generates both a enabledPlugins(address,address) function and a getPluginInfo(address,address) function unnecessarily). I think we should either generated accessor methods, or hand-written methods, but definitely not both. Since it is outside of the scope of this PR, I created a separate issue #130 to track this. The reason it is worth mentioning here is that this effectively changes the Manager interface to be slightly different - the order of parameters in the generated accessors for the public mapping has changed, but the hand-written function accessors has not (hence, the Manager still implements ISafeProtocolManager correctly).

Related to #127

[github-actions]

Pull Request Test Coverage Report for Build 6800133305

• 15 of 15 (100.0%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 6691897064:	0.0%
Covered Lines:	227
Relevant Lines:	227

---

💛 - Coveralls

[mmv08]

Looks good to me. What do you think about adding comments to explain why the mappings are defined this way? I feel this could be helpful because having a mapping from an account to a module (or any other primitive) is more natural than doing it from a module to an account and then storing the reference to the outer mapping in the inner mapping. But maybe I'm the only one who feels this way.

[nlordell]

Closed in favour of #132 with branch name that matches contribution standards.