Add opt-in `messaging.rabbitmq.vhost.name` and `messaging.rabbitmq.cluster.name` span attributes

[abhishuraina]

Is your feature request related to a problem? Please describe.

RabbitMQ spans produced by the rabbitmq-2.7 instrumentation carry no information about which
virtual host or which cluster a message was published/consumed on. Both are basic facts about a
RabbitMQ connection, and without them it's hard to distinguish traffic across vhosts (a common
multi-tenancy boundary in RabbitMQ) or to tell which cluster node/cluster a trace touched when
several clusters are monitored from the same backend.

Neither attribute is part of the messaging semantic conventions yet
(open-telemetry/semantic-conventions#3997 is tracking that), so they can't be added as stable,
always-on attributes today.

Describe the solution you'd like

Add two new opt-in, experimental span attributes to the rabbitmq-2.7 instrumentation:

• messaging.rabbitmq.vhost.name — the virtual host of the connection.
• messaging.rabbitmq.cluster.name — the broker's cluster_name server property.

Both should be disabled by default and gated behind their own configuration properties (following
the existing pattern used for otel.instrumentation.rabbitmq.experimental-span-attributes), e.g.:

• otel.instrumentation.rabbitmq.experimental.capture-vhost-name
• otel.instrumentation.rabbitmq.experimental.capture-cluster-name

The vhost should be captured off the connection itself (not just the value passed to
ConnectionFactory) so it keeps reporting correctly across RabbitMQ's automatic connection
recovery, where the underlying connection object is replaced.

Describe alternatives you've considered

No response

Additional context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}