feat: refactoring casl permission checks for recursive nested operations

[magrinj]

This PR introduces a new capability to the project: checking permissions for Prisma operations involving nested relationships. This new feature ensures that the right permissions are in place when performing complex nested operations in our database.

Key highlights include:

1. Operations Definition: Operations are categorized into 'create' and 'simple' based on the type of permission checks they require. This classification improves how we process each operation.

2. Operations Checking: We've introduced 'OperationAbilityCheckers' that conduct permission checks depending on the operation type. 'createAbilityCheck' ensures a user has the ability to create a new entity, while 'simpleAbilityCheck' checks permissions for operations like 'connect', 'disconnect', 'delete', etc.

3. Recursive Nested Operations: We have introduced a new function, relationAbilityChecker, that handles recursive nested operations. It splits each operation and checks them independently.

Here is an example of how to use these new permission checks:

@Injectable()
export class CreateCompanyAbilityHandler implements IAbilityHandler {
  constructor(private readonly prismaService: PrismaService) {}

  async handle(ability: AppAbility, context: ExecutionContext) {
    const gqlContext = GqlExecutionContext.create(context);
    const args = gqlContext.getArgs();

    const allowed = await relationAbilityChecker(
      'Company',
      ability,
      this.prismaService.client,
      args,
    );

    if (!allowed) {
      return false;
    }

    return ability.can(AbilityAction.Create, 'Company');
  }
}

[charlesBochet]

Bravo!

[charlesBochet]

I think that we should find a better naming than "simple". existing?

[charlesBochet]

const operations