[Improvement] Explicit support for semi-modular accounts

[adam-alchemy]

• For more opinionated account implementations, it should be possible to have some amount of functionality “baked-in” to the account contract. Right now this isn’t disallowed by the standard, but unfortunately other native account functions don’t have some of the “features” plugin functions have. Notably, these include the ability to call them via executeFromPlugin, they may or may not have validation functions + hooks applied over them, and it isn’t clear how the base account could itself implement validation functions and hooks. If we can devise a strategy for bringing account-native features to the same “parity” level as plugin functions, we could have a significantly easier time creating semi-modular accounts.

[huaweigu]

We can consider having a boolean flag, defaultValidationEnabled in account storage. If this flag is enabled, the account would use its own validation logic. An interface, IAccountValidator, can be defined for this purpose. If the validation requires storage access (e.g. ownerAddress), the data would also be stored in account storage. Additionally, functions within IAccountValidator must be provided to to initialize/update/remove this data. The account validation would act like root access, taking precedence over any other plugin validations.