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)
• Review comments and other in-code documentation

[ctrlc03]

if these don't change they could be set as immutable

[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?