Retry policy should support retry-after-ms

[jhendrixMSFT]

Provides sub-second retry granularity.

[trrwilson]

Thanks, @jhendrixMSFT ! Parity link dump for easy reference:

• .NET's retry handling: azure-sdk-for-net/sdk/core/Azure.Core/src/ResponseHeaders.cs at 7e7e9854d4c90fc25ee65d7729d69a8489f00d59 · Azure/azure-sdk-for-net (github.com)
• Java's retry handling: azure-sdk-for-java/sdk/core/azure-core/src/main/java/com/azure/core/implementation/ImplUtils.java at 3594e48f1b837f2c9656337a5488e867a7aa465d · Azure/azure-sdk-for-java (github.com)
• JS's retry handling: azure-sdk-for-js/sdk/core/core-rest-pipeline/src/retryStrategies/throttlingRetryStrategy.ts at 17de1a2b7f3ad61f34ff62876eced7d077c10d4b · Azure/azure-sdk-for-js (github.com)

Each of those, in the language-specific implementations, handles the three retry headers in precedence order, most succinctly in JS:

const AllRetryAfterHeaders: string[] = ["retry-after-ms", "x-ms-retry-after-ms", RetryAfterHeader];

So our "spec" is effectively "if retry-after-ms is present, use that as units of milliseconds; otherwise, if x-ms-retry-after-ms is present, use that as units of milliseconds; otherwise, if retry-after is present, use that in units of whole seconds; otherwise, use standard backoff heuristics."

[jhendrixMSFT]

Fix will be included in azcore@v1.9.1 which should go out week of 12/11.