This will help us expand in the idea of a "DeniedActor" gate, where we are actually denying access of a feature to a specific set of users

This gate will be responsible for holding the state of denied actors. When calling `Flipper.deny_actor(actor)` we want to be able to deny access of an actor to a resource, overriding any permission this actor might have to see a feature.

Now we can properly deny actors access to our code through the UI

This is the de facto implementation of the DeniedActor behavior. When checking if an actor has access to a feature, we first check if that user should be denied because of a deniable gate (currently, only the DeniedActorGate). If no gate is denying access, we fallback to the already existent implementation.

Some adapters had to be changed to support this new type of gate