Refactor to simplify scanresults model

[abraemer]

Summary of changes

• slightly improve OpossumProvider to allow construction of Opossum where review_results=None
• fix bug in ScanResults were the logic around the attribution keys assumed attribution_to_id to be a default_dict and would break otherwise.
• change fields of ScanResults that were either list | None or dict | None to disallow None and use an empty container instead. This removes some null checks throughout the codebase and requires some adaption of the tests. Mainly to the round-trip of OpossumFileModel due to the normalization of the fields.

Context and reason for change

This PR aims to simplify the internal OpossumModel by making the types on the fields stricter. This makes the subsequent implementation of merging of opossums simpler.

[Hellgartner]

Nice PR showcasing how good it is to decouple the working entities from the models directly associated to the file

The only one thing I would like to discuss is whether we should keep the change transparent for the end file, i.e. restore the Nones when converting back to the OpossumModel?
That would also mean we would avoid changing the tests

I did double check OpossumUI and from loading the data into OpossumUI there is no difference whether the entry is not part of the json at all or whether it is simply and empty dict/list.

However IMHO I would prefer keeping the .opossum files un-mutetated while processing.

[abraemer]

The only one thing I would like to discuss is whether we should keep the change transparent for the end file, i.e. restore the Nones when converting back to the OpossumModel?

However IMHO I would prefer keeping the .opossum files un-mutetated while processing.

I think the main issue here is that we cannot distinguish whether the input was missing the field or had an empty container. Thus "keeping ... unmutated" is impossible in principle. We need to make an a priori arbitrary choice whether we want to write [] or skip the field.
Personally I like that the structure we write always has all the keys. That makes it easy for someone to look at and see everything that could be there without experimentation.

[Hellgartner]

Thus "keeping ... unmutated" is impossible in principle.

Agreed, however all files we have seen up to now adhered to the principle of just leaving empty fields out. So this is a break in procedure.

[Hellgartner]

Discussed non vs empty list and agreed to keep empty list