Create an OrtResult abstraction

[mnonnenmacher]

Create an abstraction for the OrtResult to decouple the ORT tools from the way that ORT data is stored.

Currently, we access the data stored in OrtResult directly in many places. This has the downside that the tools are tightly coupled to the OrtResult class, while the OrtResult class has to be optimized for serialization at the same time, because it is used to write the result files. Creating a facade (e.g. an interface of a collection of interfaces) would have several benefits:

• We could provide different means to store ORT result data, for example a local database, and it would be easier to experiment with alternative storage formats like Protobuf.
• Breaking changes in the ORT result file format would not necessarily require changes in the interface.
• Tests often require to build large parts of an OrtResult or even a complete OrtResult, when they actually only use a much smaller part of it. In those cases mocks could be used to reduce the size of the tests.

[oheger-bosch]

This does not only affect the reading of result data but also the creation. One possible approach could be based on the builder pattern: Instead of creating result objects directly, ORT components are passed a builder they can use to propagate their results.

[sschuberth]

FYI, there's a similar topic for LicenseClassifications. Maybe it makes sense to try out a new API approach first in the context of such a smaller / isolated class.