Refactor: Introduce an internal model for opossum data

[abraemer]

Currently, we only have a model representing an Opossum file as it is written on disk as json. This is has the drawback that the current model does not enforce/reflect the semantic relationships of the resource-to-attribution mapping (involving the fields resources, resourcesToAttributions, externalAttributions). Thus every file format frontend needs to reimplement the logic of these relationships (and also all other intricacies of the disk format, like leading "/" and possibly #38 )

This can be solved by introducing another abstraction layer on top of the "opossum file"-model that reflects the semantics properly. The proposed new model has the same structure as the current one except that the resources and attribution fields are replaced by a single field with a recursive tree structure reflecting the file structure. Each node knows its full path, the attributions attached to it and its child nodes.

This internal opossum model brings the advantages:

• It is a simpler target for the frontends because there are fewer implicit dependencies to be respected which will simplify the logic in the frontends and make it less redundant.
• Conversion between the internal opossum model and the "opossum file" model takes care of mapping attributions and resources for all frontends and is thus a single point of truth for the details of the opossum file format. Implementing Expand file path only for some elements #38 here enables it consistently for all input formats.
• It allows for semantic comparison of opossum files, i.e. ignoring the arbitrary labels of the externalAttributions that are used solely to map them to files. This enables building robust tests.
• It is a better level to implement the merging of opossum files due to its structural guarantees
• It clearly separates the stages for the conversion and defines a clear interface for the frontends.