feat: add allowlist module

[adamegyed]

Add the AllowlistModule from the ERC-6900 reference implementation as a built-in module.

Provide a fork test that uses the allowlist module as a pre-validation hook over a SingleSignerValidation key.

Update the exports in @account-kit/smart-contracts to:

• Export the types of actions: AccountLoupeV08Actions and InstallValidationActions.
• Export the value of the enum HookType, not just the type.
• Reorganizes modules to their own section at the bottom.

Pull Request Checklist

• Did you add new tests and confirm existing tests pass? (yarn test)
• Did you update relevant docs? (docs are found in the site folder, and guidelines for updating/adding docs can be found in the contribution guide)
• Do your commits follow the Conventional Commits standard?
• Does your PR title also follow the Conventional Commits standard?
• If you have a breaking change, is it correctly reflected in your commit message? (e.g. feat!: breaking change)
• Did you run lint (yarn lint:check) and fix any issues? (yarn lint:write)
• Did you follow the contribution guidelines?

---

PR-Codex overview

The focus of this PR is to add two new modules, SingleSignerValidationModule and AllowlistModule, along with their ABIs and tests.

Detailed summary

• Added SingleSignerValidationModule with ABI and encode functions
• Added AllowlistModule with ABI and encode functions
• Updated exports in index.ts for new modules

The following files were skipped due to too many changes: account-kit/smart-contracts/src/6900-v08-RI/modules/allowlist/module.test.ts

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
aa-sdk-site	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 12, 2024 4:12pm
aa-sdk-ui-demo	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 12, 2024 4:12pm

[moldy530]

can you explain this? what's your ideal devex?

[adamegyed]

Ah this is just a todo for later, but basically it'd be nice to have a base "class" or other util for creating module definitions that just takes in:

• An address record
• Name / meta info
• The parameter formats for onInstall / onUninstall

And it could produce something that fits the interface I created and have been using so far. I don't think it needs to be as heavyweight as the old plugingen, since most config formats are now off-chain rather than in the manifest, but it would be nice to have an enforced interface / type for the modules.