Exception refinement: Adding additional information

[Ignacio Inglese (iNinja)]

Exception refinement: Adding additional information.

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• If any gains or losses in performance are possible, you've included benchmarks for your changes. More info
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Refining the agreed model to simplify where possible and match the original validation path's output.

Description

• Removed generic error from Result type. All uses share the same constant error type. Removing it from the generic simplifies our interfaces and makes the code easier to read.
• Restored use of Activator to instantiate the exceptions in an AOT compatible manner.
• Added initial proposal of extending ExceptionDetail to assign additional information to exceptions

Notes:

For the additional data, 3 approaches were evaluated:

• Creating specialised result types: this results in a lot of code duplication if we want to keep our value type result, or an extra allocation if we turn it into a class to use inheritance.
• Passing a dictionary to ExceptionDetail that can then be used to extract the information in each exception results in an extra allocation of the dictionary.
• Extending ExceptionDetail to allow the provision of specialised classes that receive the extra data and assign it only when the exception is instantiated. This was the chosen path forward for this PR since it avoids any new allocations and allows extensibility between ExceptionDetail subclasses and Exception subclasses. It makes no assumptions about the types.

Part of #2711