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. - [ ] Mandatory Add the required version to the Fix version/s field. 2.11.0

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

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

3. - [x] Mandatory for GA content:
            
       - [x] Add steps and/or other important conceptual information here: 
       During the design of OperatorPolicy, we identified scenarios where different users may want different compliance behaviors from their policies: for example, some users will want to be notified via a violation that an upgrade is available for their operator, while other users may want the policy to remain compliant as long as it is an allowed version, and it is healthy in other respects. In the initial implementation for the Technical Preview, we chose a specific behavior for each of those scenarios, and it was not configurable by the user. In the 2.11 release, along with it going GA, we have made the behaviors configurable, as well as changed the "default" behavior in some cases. The new `spec.complianceConfig` field in OperatorPolicy allows the user to configure the behavior for each case, but is not required to be set.
            
       - [x] Add Required access level for the user to complete the task here:
       policy admin

       - [x] Add verification at the end of the task, how does the user verify success (a command to run or a result to see?)
     not a task
     
       - [x] Add link to dev story here: https://issues.redhat.com/browse/ACM-11023 

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

Current doc: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html-single/governance/index#policy-operator or in github: https://github.com/stolostron/rhacm-docs/blob/2.11_stage/governance/policy_operator.adoc

Add a new row to the table, for `spec.complianceConfig`. It is optional. Description: Define the compliance behavior for specific scenarios associated with operators. For each of these, the options are "Compliant" or "NonCompliant". 

• `catalogSourceUnhealthy`: define the compliance when the catalog source for the operator is unhealthy. Defaults to Compliant, because this only affects possible upgrades.
• `deploymentsUnavailable`: define the compliance when the deployment(s) of the operator is not fully available. Defaults to NonCompliant, because this reflects the availability of the service the operator provides.
• `upgradesAvailable`: define the compliance when there is an upgrade available for the operator. Defaults to Compliant, because the existing operator installation may still be running correctly.

It may be worth noting that each of these can be set individually; setting one does not require the user to set the others.