Document API Decisions for Module Registration

[nlordell]

Currently, module registration in the SafeProtocolRegistry and plugin permissions in the SafeProtocolManager use uint8 constants for specifying bitflags.

This issue captures some of the work to both document and re-evaluate the APIs to ensure that they are optimised for their uses:

• The assumption is that module registration will mostly be initiated off-chain, which means that it might make sense to consider using Solidity enums as they have better integration with things like Ethers, TypeChain, etc.
• The assumption is that check calls on modules would be called on-chain, where bitflags are more natural to use with constants instead of enums. In that case, the API should probably be implemented as it currently is in function of uint8 constants.

We should also consider whether it is worth having a higher API surface (i.e. support both enums and bitflags simultaneously) which increases cognitive load when trying to understand the interface.

On-Chain Usage of Enums vs Constants:

enum ModuleType {
  Plugin,
  Hook,
}

// usage:
ModuleType[] memory types = new ModuleType[](2);
types[0] = ModuleType.Plugin;
types[1] = ModuleType.Hook;

library ModuleTypes {
    uint8 constant PLUGIN = 1;
    uint8 constant HOOK = 2;
}

// usage:
uint8 types = ModuleTypes.PLUGIN | ModuleTypes.HOOK;