Refactor and advance core framework capabilities

[0xjei]

This PR extends the core framework's functionality based on #5 conversations and more.

• There will be a Base and Advanced gatekeeper division with reusable Checker contracts. This is a huge breaking change compared to previous prototype implementation on zk-kit.
• The usage of a nested mapping mapping(address => mapping(address => bool)) can make us able to simulate different deployed instances of Excubiae Gatekeeper and maintain a reference like 1 contract <> N independent states (who already passed the gatekeeper). This will allow us to get rid of the non-determinism in deployments and maintain a structure where navigating and managing the different gatekeepers smoothly.
• Making the checks to return a boolean.

The change will allow for other changes, as:

• Checker independent contract instead of check() method
• Base and Advanced separation of concerns for Excubia and Checker contracts
• Common mappings to handle AlreadyPassed checks & logic
• Use mapping of mapping to handle 1 contract <> N independent gatekeeper states
• Checks must return a bool
• Separation of concerns for Excubia extensions (FreeForAllExcubia)
• Apply new naming and conventions
• Pattern: balance _internal vs external methods
• Full code coverage (create a fixture for base & advanced for testing purposes)
  • Configs
  • Base
    • BaseChecker
    • BasePolicy
    • BaseVoting (integration)
  • Advanced
    • AdvancedChecker
    • AdvancedPolicy
    • AdvancedVoting (integration)
• Refactoring
• Review code comments and other in-code documentation

[ctrlc03]

what's the reasoning behind storing addresses as a base? imagine a ERC721 policy, they could transfer the token id to another wallet and pass again? wouldn't the type of data to be stored need to be custom for each policy?

[0xjei]

The base address-to-address mapping serves as a fundamental tracking mechanism for policy enforcement. While this may seem simple, it's intentionally designed this way for two reasons:

• The policy's primary role is binary - tracking whether a subject has enforced evidence for an address. Complex validation logic (like NFT ownership changes) belongs in policy checker extensions - not at core functionality level (the gatekeeper must enforce and keep track, based on the checks).
• Additional checks and restrictions are implemented at the Checker level, not the Policy level. For example, AdvancedERC721Checker under the test/advanced folder can track used tokenIds to prevent reuse - this is where such specific validation belongs.

This design maintains clean separation between basic enforcement tracking and policy-specific validation rules. Let me know if this makes sense!