[Feature] Add priority field to ResourceBinding

[Vacant2333]

What would you like to be added:
I want to add a Priority field to ResourceBinding. In this issue (#4937), I mentioned supporting the suspension of ResourceBinding to enable Karmada to manage queues externally. However, just having this one field is actually not enough, because we might need to sort the loads in the queue based on priority. For example:

As a user, I hope to deploy higher-priority loads first when cluster resources are insufficient.

Additionally, we can consider scenarios of multi-tenancy and capacity management. For instance, a company may have multiple departments, each with different priorities and capacities.

Why is this needed:
I hope to enable queuing capabilities while supporting load sorting by priority, so that higher-priority loads (such as DB, Gateway, high-priority AI computing tasks) can be scheduled to the worker cluster first.

How to implement it:
I have two implementation ideas:

1. Obtain the priority through the PriorityClass of the Resource when creating ResourceBinding.
2. Specify the priority in some way (e.g., by adding a specific label to each resource) when the user creates the PropagationPolicy.

The biggest difference between these two approaches is the ability to separate the priority of each scheduling instance. In a single cluster, the priority of the resource itself (PriorityClass) is sufficient. However, in a multi-cluster scenario, I'm not sure if we need to distinguish between the priority of scheduling in Karmada and the priority of scheduling in the worker cluster.

Approach 1 essentially uses the same priority for bothKarmada control plane scheduling and worker cluster scheduling. Additionally, we need to consider whether the corresponding PriorityClass needs to be propagated to the worker cluster.

Approach 2 separates the priority of Karmada control plane scheduling from the priority of worker cluster scheduling. It marks the priority during control plane scheduling by adding a specific annotation or label to the resources that need to be scheduled in the PropagationPolicy.

Of course, Approach 2 is more complex than Approach 1. This is just my rough outline, and I'm not sure if we need to consider this issue. Perhaps we can directly implement Approach 1.

[whitewindmills]

see #4993