Create an informative issue (See each section, incomplete templates/issues won't be triaged)

Using the current documentation as a model, please complete the issue template. 

Note: Doc team updates the current version and the two previous versions (n-2). For earlier versions, we will address only high-priority, customer-reported issues for releases in support.

Prerequisite: Start with what we have

Always look at the current documentation to describe the change that is needed. Use the source or portal link for Step 4:

 - Use the Customer Portal: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes

 - Use the GitHub link to find the staged docs in the repository: https://github.com/stolostron/rhacm-docs 

Describe the changes in the doc and link to your dev story

Provide info for the following steps:

1. - [x] Mandatory Add the required version to the Fix version/s field.

2. - [x] Mandatory Choose the type of documentation change.

      - [x] New topic in an existing section or new section
      - [ ] Update to an existing topic

3. - [x] Mandatory for GA content:
            
       - [x] Add steps and/or other important conceptual information here: 
       Currently, it is possible to create a ConfigurationPolicy for an OLM subscription to install an operator, but without additional policies, it is difficult to verify the status of the installation. The new OperatorPolicy type eases this process with just one policy. For example:

apiVersion: policy.open-cluster-management.io/v1beta1
kind: OperatorPolicy
metadata:  
  name: oppol-with-group
spec:  
  remediationAction: enforce # or inform
  severity: medium  
  complianceType: musthave
  operatorGroup: # optional    
    name: scoped-operator-group    
    namespace: operator-policy-testns    
    targetNamespaces:      
      - operator-policy-testns
  subscription:    
    channel: stable-3.8    
    name: project-quay    
    namespace: operator-policy-testns    
    installPlanApproval: Automatic # or manual    
    source: operatorhubio-catalog    
    sourceNamespace: olm    
    startingCSV: quay-operator.v3.8.1

Several things to note:

• After applying a valid OperatorPolicy, the controller will create the `operatorGroup` and `subscription` objects on the cluster, which then prompts OLM to handle the rest of the installation process (We assume OLM is already installed on the cluster, and it must be for OperatorPolicy to work). The controller will report back the health of owned resources in the `.status.Conditions` and `.status.relatedObjects` fields.
• The `operatorGroup` field is optional and can be generated by the OperatorPolicy controller. By default, if the `operatorGroup` field is not specified, the controller generates an `AllNamespaces` type OperatorGroup in the same namespace as the subscription, if supported.
• If the `installPlanApproval` field is set to manual, the user needs to manually patch the `.spec.approved` field in the relevant InstallPlan to proceed with the installation process. The `InstallPlan` for an operator is generated after the subscription is created by the controller, and represents the intention to install a specific version of the desired operator.

           
       - [ ] Add Required access level for the user to complete the task here:

       - [x] Add verification at the end of the task, how does the user verify success (a command to run or a result to see?)
     Using kubectl to check that the status field of the OperatorPolicy is being populated and that the correct operator deployment is available on the cluster.
     
       - [x] Add link to dev story here: https://issues.redhat.com/browse/ACM-6652

4. - [ ] Mandatory for bugs: What is the diff? Clearly define what the problem is, what the change is, and link to the current documentation: