[Service Bus] Consolidate the message model and expose the raw AMQP message

## Summary

`Message` and `ReceivedMessage` duplicate field definitions and conversion logic, several fields are exposed as `HashMap`, and there is no access to the underlying AMQP annotated message.

## Motivation

.NET splits `ServiceBusMessage` from `ServiceBusReceivedMessage` but lets both construct from and expose an `AmqpAnnotatedMessage`. Go does the same with `AMQPAnnotatedMessage`. Callers need that escape hatch for headers the typed surface does not model.

The crate also lacks `ServiceBusMessageState`, which reports whether a message is active, deferred, or scheduled.

## Proposal

- Consolidate the shared field set and the AMQP conversion.
- Expose the raw AMQP annotated message on both types.
- Add a message state type.
- Replace the exposed `HashMap` fields with an accessor that does not pin the representation.
- Decide whether the model types need serde at all.

## Related

Sub-issue #2923 asks whether the model types really need serde.

## Dependencies

Blocked by:

- #4941 [Service Bus] Settle the public API shape before API review

Sub-issue of #4934.

Begin with the blocked API-shape discussion in issue #4941, then review the existing Message and ReceivedMessage models and the serde question in sub-issue #2923. Done means the shared model and AMQP conversion approach, raw annotated-message exposure, message state type, map accessor, and serde decision are settled for API review.

Written by the indexing model from the issue text.