Guide user about the `authorize` command

[pPrecel]

Description

User should be informed about all possibilities when running the kyma alpha authorize --help command.

The kyma alpha authorize works with four sub-commands/arguments: user, group, serviceaccount, and repository. The first three work as arguments for the authorize command, and the fourth one is a separate sub-command with different available flags. This separation make sens from the developers' perspective to split logic based on available flags, but from the users' perspective, this makes no sense, because users see authorize repository, authorize user, authorize group, or authorize serviceaccount. Users want to authorize the given abstract unit, no matter if this unit is represented by a sub-command or an argument.

This is the kyma alpha authorize --help output:

Create a RoleBinding or ClusterRoleBinding that grants access to a Kyma role or cluster role for a user, group, or service account.

Usage:
  kyma alpha authorize <authTarget> [flags]
  kyma alpha authorize [command]

Examples:
  # Bind a user to a namespaced Role (RoleBinding)
  kyma alpha authorize user --name alice --role view --namespace dev

  # Bind multiple users to a namespaced Role (RoleBinding)
  kyma alpha authorize user --name alice,bob,james --role view --namespace dev

  # Bind a group cluster-wide to a ClusterRole (ClusterRoleBinding)
  kyma alpha authorize group --name team-observability --clusterrole kyma-read-all --cluster-wide

  # Bind a service account to a ClusterRole within a namespace (RoleBinding referencing a ClusterRole)
  kyma alpha authorize serviceaccount --name deployer-sa --clusterrole edit --namespace staging

  # Preview (dry-run) the YAML for a RoleBinding without applying
  kyma alpha authorize user --name bob --role operator --namespace ops --dry-run -o yaml

  # Generate JSON for a cluster-wide binding
  kyma alpha authorize user --name ci-bot --clusterrole kyma-admin --cluster-wide -o json

Available Commands:
  repository  Configure trust between a Kyma cluster and a GitHub repository

Flags:
      --cluster-wide          Create a ClusterRoleBinding for cluster-wide access (requires --clusterrole)
      --clusterrole string    ClusterRole name to bind (for ClusterRoleBinding with --cluster-wide, or RoleBinding in namespace)
      --dry-run               Preview the YAML/JSON output without applying resources to the cluster
      --name strings          Name(s) of the subject(s) to authorize (required)
      --namespace string      Namespace for RoleBinding (required when binding a Role or binding a ClusterRole to a specific namespace)
  -o, --output string         Output format for dry-run (yaml or json)
      --role string           Role name to bind (creates RoleBinding in specified namespace)
      --sa-namespace string   Namespace for the service account subject. Defaults to the RoleBinding namespace when not specified.

Global Flags:
      --context string          The name of the kubeconfig context to use
  -h, --help                    Help for the command
      --kubeconfig string       Path to the Kyma kubeconfig file
      --show-extensions-error   Prints a possible error when fetching extensions fails
      --skip-extensions         Skip fetching extensions from the target Kyma environment

Use "kyma alpha authorize [command] --help" for more information about a command.

Our examples in this section point to argument-based functionality only, but if the user is interested in authorizing a repository, we must run the kyma alpha authorize repository --help command. I think this logic is masked by argument-based functionality and its examples.

AC:

• All cases are represented by sub-commands like (user, group, serviceaccount, repository)
• The kyma alpha authorize should not be executable and print help only
• The help view should contain information about possible sub-commands and a section describing which sub-command use for which use-case