Create a new section in 1.5.18.3 to introduce global KlusterletConfig.

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

https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10/html/clusters/cluster_mce_overview#advanced-config-cluster 

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

1. Add a new section to introduce the global KlusterletConfig.

In ACM 2.11, we introduced a new concept of KlusterletConfig – the "global" KlusterletConfig.

If a user creates a KlusterletConfig and named it "global", then the user doesn't need to bind a managed cluster to a KlusterletConfig via annotation, the configurations in the 'global' KlusterletConfig will automatically be applied on every managed cluster.

If the environment already has a "global" KlusterletConfig exist, and the user creates another KlusterletConfig and bind it with a managed cluster. There are 2 cases:

Case1: both "global" and specified KlusteletConfig confiugred this field, using `hubKubeAPIServerURL` for example:

```

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerURL: "example.test.com"
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.global.com"

```

In this case, the field of the specified KlusterletConfig will override the global value. And hubKubeAPIServerURL: "example.test.com" takes effects.

Case2:  the filed of the specified KlusterletConfig doesn't exist or has a zero value.

```

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
spec:
  hubKubeAPIServerURL: ""
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.global.com"

```

or 

```

apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: test
—
apiVersion: config.open-cluster-management.io/v1alpha1
kind: KlusterletConfig
metadata:
  name: global
spec:
  hubKubeAPIServerURL: "example.global.com"

```

In this case,  the "global" value hubKubeAPIServerURL: "example.global.com" will take effect.

—

2. Mention in the doc where used `KlusterletConfig`that they can use the "global" KlusterletConfig to enable the desired configuration on every managed cluster. And create a hyperlink points the new nection of the global KlusterletConfig.

1.5.18.2.1 step 2 Note, Add "You can also using a global KlusterletConfig to enable the configuration on every managed cluster without binding via annotation"

1.5.18.3.2 step 2 note: the same as the above

Provide info for the following steps:

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

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

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

3. - [x] Mandatory for GA content:
            
       - [ ] Add steps and/or other important conceptual information here: 
       
            
       - [ ] Add Required access level for the user to complete the task here:
       

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

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