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

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 otel.instrumentation.rabbitmq.experimental-span-attributes flag — the same flag that already gates this module's other experimental attributes (rabbitmq.command, rabbitmq.delivery_mode,
rabbitmq.queue, rabbitmq.record.queue_time_ms)

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.}

Start by locating the rabbitmq-2.7 instrumentation and the existing experimental span attributes gated by otel.instrumentation.rabbitmq.experimental-span-attributes. Trace how the active connection is accessed during publishing and consuming, including automatic recovery. Done means both requested attributes are opt-in, disabled by default, and report the connection's vhost and broker cluster name.