LRO POST Responses checks are broken

[markcowl]

This PR made two changes that regress how LRO POST operations are supposed to work: https://github.com/Azure/azure-openapi-validator/pull/784/files

First, the POST operation itself only actually returns a 202 or an error response. Any 200 or 204 response is the result of subsequent polling using GET requests of the uri in location or other headers. This is consistent with the RPC, which describes the 200 or 204 response after subsequent requests.

Second, we used to add a "fake" 200 response for LRO POST with a schema or a "fake" 204 responses for LRO POST without a schema, so that clients understood what the eventual response would be after polling.

A few years ago, we stopped requiring the "fake" 204 response for responses without a schema, because all consumers of swagger understood the lack of a 200 response to mean a void response after polling.

We also started supporting x-ms-long-running-operation-options.final-state-schema to indicate the final state schema, with its absence indicating a void response as an alternative to these fake responses.

It is entirely safe to require either a 200 response or a final-state-schema for lro POST operations that return a non-void result.

It is also entirely safe to require just a 202 for lro POST operations with a void result.

This is what the rule should check for.

This is currently breaking TypeSpec POST LROs, which were specifically changed to accommodate the 202-only for POST operations when this rule was changed a few years ago.

At the very least, there needs to be discussion about these rule changes with the TypeSpec team before we create new violations.