Add support for status 200, 201 for LRO delete operation

[AllyW]

Clear and concise description of the problem

For now, autorest asks for 202, 204 and default error response for long-running delete operation (according to openapi validator here: https://github.com/Azure/azure-openapi-validator/blob/main/docs/delete-response-codes.md#output-message), conceptually. And tsp compiler also emits only 202, 204 and default error response for LRO delete operation.

However, in execution level, all sdks and other autogen tools need to append an additional operation for 200 or 201 status after getting a successful 202 polling result, which normally is in status 200.

And, there remains some apis whose LRO delete operation contains a 200 response for a successful 202 polling result (like this one: https://github.com/Azure/azure-rest-api-specs/blob/main/specification/monitor/resource-manager/Microsoft.Insights/PrivateLinkScopes/preview/2023-06-01-preview/privateLinkScopes_API.json#L543-L599),
If 200 is dropped for these apis, I believe this might be a breaking change from swagger side?

Also, as a new spec language, it should be better to fill the concept and practice gap on LRO delete operation, and to simplify all the downstream's emitters' code base with no redundance on these field.

Checklist

• Follow our Code of Conduct
• Check that this issue is about the Azure libraries for typespec. For feature request in the typespec language or core libraries file it in the TypeSpec repo
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[markcowl]

The 200 response after the initial 202 is implied by the lro information provided by lro APIs in Azure.Core. In most brownfield APIs that have a 200 response, there is not actually a 200 response returned by delete, but a 200 returned by the subsequent 'get' of the location or Azure-AsyncOperation header. We should not represent operation responses that are not returned by the operation being documented, even though we did this in swagger to make client generation easier. Equivalent information is available through APIs.

The purpose of the templates in the ARM library is not to represent every possible API, but to encourage new APIs to use best practices, which includes only returning 202 from delete operations, as enforced by lintdiff rules. For brownfield operations that are outside current best practices, specifications should use lower level templates. Note that there is an async delete operation template that returns a 200 as shown here, but this should only be used if the delete operation can actually return a 200 itself. If there really are APIs that return a 201 (created) from delete, and this isn't a spec mistake, then these would need to be represented using lower level templates.