[Design] [FormRecognizer] Handle operation failed status consistently across Recognize and Train LROs

[kinelski]

Summary

When a training operation fails, no exception is thrown. The developer needs to manually check their model status and errors to assert it has succeeded before actually making use of the model.

var op = await trainingClient.StartTrainingAsync(...); // POST request succeeds
await op.WaitForCompletionAsync(); // GET request succeeds and returns a failed operation

// op.Value.Status must be checked.

Getting no exceptions could be misinterpreted as a sign that the training operation has succeeded.

However, throwing an exception in case of failure could be risky as well. It could give the developer the impression that the whole operation has failed and that no model has been created. They should be able to immediately retrieve the model id and delete it if desired. The current implementation allows that.

Goals

• Discuss with the team what the expected behavior should be.
• If necessary, update the client code so it can behave as expected.
• Create tests to validate the chosen approach.
• Make sure existing tests still pass reliably.

[annelo-msft]

In addition:

• Handle RecognizeReceipt and RecognizeContent LROs the same way as RecognizeCustomForms (per [FormRecognizer] Consider handling failed status for receipts and content operations #11474)
• Ensure we're consistent across the LROs regarding the exception we throw when the operation fails
• Ensure we're consistent across the LROs regarding how we return Value when the operation failed (per Design how to expose Value in TrainingOperation if training fails. #10392, Consider throwing from LRO's .Value when OperationStatus.Failed. #11466)
• Look at [CodeGen] Move to .NET Code Gen LROs #11417 in parallel -- if code gen gives us most of what we need, this work could be very small. If it doesn't, let's close the code gen issue with no action.

[annelo-msft]

@kristapratico working on this on the Python side: Azure/azure-sdk-for-python#11323