Update Adapter Access Control Logic

[Kayanski]

This PR aims at updating the Access Control for actions via the account.

Proposed changes:

• Merge All actions on the account (ExecOnModule, ModuleActions) to a single LocalAction variant
  • ExecOnModule simply fetches the module address and dispatches the message
• Add a ConfigureModule message on the account for sending admin calls to modules
• Enforce this access control inside Adapter Base Variant
• Modify the NestedAmin structure to be able to account for this admin change

This is Options 2 here, there is a mermaid diagram at the end to understand the situation a little better https://www.notion.so/abstract-money/Merging-Abstract-Account-Implementation-6d366bb35b3242adb6ae5787fb759cc8?pvs=4

Checklist

• CI is green.
• Changelog updated.

[cloudflare-workers-and-pages]

Deploying abstract-docs with    Cloudflare Pages

Latest commit:	74064d3
Status:	✅  Deploy successful!
Preview URL:	https://8665d12c.abstract-docs.pages.dev
Branch Preview URL:	https://nicolas-abs-514-update-adapt.abstract-docs.pages.dev

View logs

[Buckram123]

Looks good! Noticed one edge case, which I hope is unlikely to happen

[CyberHoward]

Namely, today only the admin (might be the account) OR the top level owner can execute on the admin variants. We need to modify the NestedAdmin structure to be able to verify that IF the admin is an account, it should be in an admin state. Is that an acceptable behavior

Yes, I think this is the behavior we want. A nucance here is that we want to do the admin-flag assertion on the direct admin of the app (i.e. the account that the app is installed on) vs the top-level account. Because an admin action on a sub-account should not require an admin flag be set on the owner account.

[CyberHoward]

Could you update packages/abstract-std/src/objects/ownership/README.md with an explanation of how the CALLING_TO_AS_ADMIN value is used?