[Feature] consumer tag

### Is Your Feature Request Related to a Problem?

No

### Describe the Solution You'd Like

**The consumer client supports defining a consumer-tag and consumer-tag-filter-conditions.**

* **consumer-tag**: The label defined by the consumer client for itself, not to the message. Different consumers within the same consumer-group can be configured with different tags.

* **consumer-tag-filter-conditions**: Filtering criteria defined by the consumer client based on message attributes, determining which messages can match the current consumer-tag; this is different from the filtering expressions used in subscription.

**Constraints**

* Each consumer is allowed to have only one tag (consumer-tag).

* There must be a one-to-one correspondence between consumer-tag and filter-conditions; within the same consumer group, it is strictly prohibited to have one consumer-tag associated with multiple filter-conditions.

* Consumers without a configured tag will be treated as having the default tag.

* Only pop consumers are supported.

**Changes on the broker side**

When a consumer pulls messages, it can only retrieve messages that match its consumer-tag.

**Fallback**

Perhaps we can incorporate the fallback configuration into the subscription. When fallback is allowed, messages that fail to match a specific consumer-tag will be consumed by the consumer with the default tag; when fallback is not allowed, unmatched messages can be routed to a dead-letter queue.

**Note📢**

The subscription remains unchanged; the consumer-tag is only used to determine which specific consumer within the consumer group will consume the messages delivered to the group.

**Scenario without consumer-tag**

**Scenario with consumer-tag**

### Describe Alternatives You've Considered

Reference: https://github.com/apache/rocketmq/issues/8468

This approach requires producers to cooperate in tagging, involves heavier publishing overhead, and cannot flexibly support multiple environments.

### Additional Context

In RocketMQ, all consumers under a consumer group evenly consume messages from the subscription. However, in certain scenarios, it is desired for different consumers to consume different messages (e.g., multi-environment deployments, canary releases, etc.).

Although this can be achieved by creating separate consumer groups, it introduces additional operational overhead and lacks flexibility, making it unable to support fallback scenarios.