[Service Bus] Replace ServiceBusError with azure_core::Error and a failure reason

## Summary

`azure_messaging_servicebus` defines its own `ServiceBusError` and `ErrorKind`. The repository convention is `azure_core::Error`. The current error type also has no retriability signal, and its kind list does not match the service.

## Motivation

`Azure.Messaging.ServiceBus` models failures as one exception type carrying a `ServiceBusFailureReason` with 13 members: `GeneralError`, `MessagingEntityNotFound`, `MessageLockLost`, `MessageNotFound`, `MessageSizeExceeded`, `MessagingEntityDisabled`, `QuotaExceeded`, `ServiceBusy`, `ServiceTimeout`, `ServiceCommunicationProblem`, `SessionCannotBeLocked`, `SessionLockLost`, and `MessagingEntityAlreadyExists`.

Retriability is a separate axis. `ServiceBusException.IsTransient` is true only for `ServiceCommunicationProblem`, `ServiceTimeout`, and `ServiceBusy`. The current Rust error carries no equivalent, so the retry policy in #4939 has nothing to switch on.

## Proposal

- Move the error to `azure_core::Error` and keep a Service Bus specific kind.
- Add a failure reason with the 13 members above.
- Add a transient flag derived from the reason, and keep it orthogonal to the reason itself.
- Map AMQP described errors and management `statusCode` values onto the reason.

## Related

Sub-issues #2920, #2921, and the closed #2922 all describe defects in the current error type.

Sub-issue of #4934.

Start by locating the azure_messaging_servicebus error definitions and the AMQP described-error and management statusCode mapping paths. Trace how errors reach callers, then verify that azure_core::Error carries the 13 Service Bus failure reasons and that transient status is separate and limited to ServiceCommunicationProblem, ServiceTimeout, and ServiceBusy.

Written by the indexing model from the issue text.