feat: Replace RBACRule with RBACRoleRule

[mattwelke]

Issue

Resolves #215

Description

The original RBAC rule behaved somewhat "magically". It ensured that a security principal had all the specified permissions, but did not allow the Validator user to validate which roles provided the permissions and how it provided them. For example:

• The role's type (built-in vs. custom)
• The role's display name
• The scope at which the role was applied via a role assignment (being able to validate this helps prevent over-permissioning)
• The exact way the permissions were defined in the role (also helps prevent over-permissioning)

Another disadvantage was that the spec did not allow wildcards because of the algorithm the controller used.

This new rule addresses the above problems. It allows users to validate that a role is applied via a role assignment to a security principal at an exact scope. It uses the role assignment and role definition REST APIs from Azure.

Example:

apiVersion: validation.spectrocloud.labs/v1alpha1
kind: AzureValidator
metadata:
  name: azurevalidator-rbacrole-one-role-assignment
spec:
  auth:
    implicit: false
    secretName: azure-creds
  rbacRoleRules:
  - name: rule-1
    principalId: 09d6f010-cda3-41a2-a853-5a1bfe448f58
    roleAssignments:
    - scope: /subscriptions/cdd14191-5cc7-4d80-83c1-524a3046b9bd
      role:
        name: MyCustomRole
        type: CustomRole
        permission:
          actions:
          - Microsoft.Compute/virtualMachines/write

Also removes kubebuilder MaxLength annotations from strings in the spec that don't need it because they aren't used with other kubebuilder validations where string length is problematic (e.g. ensuring uniqueness).

Also removes the ActionStr type because its only purpose was to support MaxLength validation, and actions/dataActions/notActions/notDataActions do not need max length validation.

[mattwelke]

As discussed offline, we will be sticking with the original rule since it achieves our goal of validating that a particular security principal has at least a particular set of permissions at a particular scope (multiple times, one for each scope), without support for wildcards, "not actions", and "not data actions" being required right now.