Add ARM pipeline policies

Feature Summary

Add policies for ARM

Feature Description

ARM has specific config for retries, timeouts, and other settings. Additionally, it handles the RP registration failures. See Go's impl for additional details, https://github.com/Azure/azure-sdk-for-go/blob/main/sdk/azcore/arm/runtime/policy_register_rp.go#L119

Additional Context

1. Analysis and Design
   Deep Dive into Go Implementation: Analyze the Go SDK's policy_register_rp.go to extract the exact state machine:
   Detection: Identification of error code MissingSubscriptionRegistration in 403/409 responses.
   Action: Triggering a POST request to the provider's /register endpoint.
   Polling: Checking the registration state until it reaches Registered.
   Integration Point: Determine the placement for these policies. Based on the repo structure, they should likely reside in sdk/core/azure_core/src/http/policies/arm/ or as a specialized ARM management crate.
2. Component Implementation
   RPRegistrationPolicy:
   Implement the Policy trait from azure_core.
   Error Parser: Develop a robust JSON parser for ARM error responses to identify the specific registration error and extract the target ResourceProviderNamespace.
   Registration Client: Implement a lightweight, internal HTTP caller to perform the POST /register and the subsequent polling GET requests.
   Async Polling: Utilize a polling loop with backoff (e.g., using tokio::time::sleep) to wait for registration completion before retrying the original request.
   ARMRetryPolicy:
   Implement or extend the existing RetryPolicy to handle ARM-specific status codes (e.g., 429 for throttling).
   Add logic to respect ARM-specific headers such as x-ms-ratelimit-remaining-subscription-writes and standard Retry-After.
3. Pipeline Integration
   Policy Ordering: Ensure the RPRegistrationPolicy is placed correctly in the pipeline (typically before or as part of the retry logic) so that the entire operation can be transparently retried upon success.
   Client Configuration: Update ARM-specific client constructors (or ClientOptions) to include these policies by default, allowing users to opt-out if necessary.
4. Verification and Testing
   Mock Transport Tests: Use the MockHttpClient to simulate the end-to-end flow:
   Initial request fails with MissingSubscriptionRegistration.
   Policy sends a POST to register the provider.
   Policy polls the provider status (handling Registering states).
   Original request is automatically retried and succeeds.
   Unit Tests: Create specific tests for the ARM error parsing logic to handle various edge cases in service responses.
5. Documentation and Best Practices
   API Documentation: Document the new policies, explaining how the auto-registration works and the default retry intervals.
   Usage Examples: Provide examples of how to customize these policies within a management-plane client.