[FEATURE] Enhance LRO in mgmt to reduce API surface

[weidongxu-microsoft]

There is certain trends on mgmt swagger on LRO.

1. some explicitly add Retry-After, Location, Azure-AsyncOperation header in swagger for LRO (traditionally they are implied by x-ms-long-running-operation and is not specified explicitly)
2. ARM seems asking service to document the polling endpoint for LRO (I am asking for material from service on whether ARM ask this as guideline)

PR Azure/azure-rest-api-specs#18435

1. https://github.com/Azure/azure-rest-api-specs/blob/8c68ad16a14d1f89a5ec278eb1e00b4767ad1ed0/specification/mediaservices/resource-manager/Microsoft.Media/stable/2021-11-01/Accounts.json#L1004-L1018
2. https://github.com/Azure/azure-rest-api-specs/blob/8c68ad16a14d1f89a5ec278eb1e00b4767ad1ed0/specification/mediaservices/resource-manager/Microsoft.Media/stable/2021-11-01/Accounts.json#L1692

Both of them might result more client/class in SDK and potentially enlarge the breaking change surface (e.g. Location and Azure-AsyncOperation basically serve same purpose).

And so far these new client/class might not have much benefits for end user, as they likely don't know what Azure-AsyncOperation header means, and they will likely not figure out how to find the "operationId" to call the polling endpoint on the new client.

Java will likely going to ignore the headers for LRO in (1). Since mgmt does not expose activation method for LRO, and begin client method only generate SyncPoller<PollResult<MediaServiceInner>, MediaServiceInner> without header.

But we might not have good solution for (2), as it could be hard to automatically figure out what kind of operation group this is.