Add reader for Trivista .tvf format

[pietsjoh]

Description of the change

Add support for reading the .tvf-format from trivista.

Progress of the PR

• basic load functionality (data, axes, original_metadata)
• metadata mapping
• provide option to load glued data as stack
• metadata mapping when loading all metadata
• time series
• axis units
• update docstring (if appropriate),
• update user guide (if appropriate),
• add an changelog entry in the upcoming_changes folder (see upcoming_changes/README.rst),
• Check formatting changelog entry in the readthedocs doc build of this PR (link in github checks)
• add tests
• check on metadata
• clean up commit history
• ready for review.

Minimal example of the bug fix or the new feature

from rsciio.trivista import api
api.file_reader("test.tvf")

[codecov]

Codecov Report

Base: 83.52% // Head: 84.71% // Increases project coverage by +1.18% 🎉

Coverage data is based on head (d52ed3a) compared to base (055822e).
Patch coverage: 99.20% of modified lines in pull request are covered.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #27      +/-   ##
==========================================
+ Coverage   83.52%   84.71%   +1.18%     
==========================================
  Files          49       58       +9     
  Lines        8390     8787     +397     
  Branches     1893     1952      +59     
==========================================
+ Hits         7008     7444     +436     
+ Misses        909      881      -28     
+ Partials      473      462      -11     

Impacted Files	Coverage Δ
rsciio/trivista/_api.py	99.19% <99.19%> (ø)
rsciio/trivista/__init__.py	100.00% <100.00%> (ø)
rsciio/conftest.py	42.85% <0.00%> (-28.58%)	⬇️
rsciio/image/api.py	89.15% <0.00%> (-2.41%)	⬇️
rsciio/nexus/api.py
rsciio/netcdf/api.py
rsciio/ripple/api.py
rsciio/prz/api.py
rsciio/protochips/api.py
rsciio/phenom/api.py
... and 14 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[jlaehne]

Note that we are changing the API slightly to expose the file_reader directly without referencing .api for each plugin, additionally we provide some standard strings for the docstrings and docstrings will be loaded into the user guide.

The documentation is adapted in #62

Would be great if you could adapt the PR sometime along the way (if anything is unclear, please leave feedback for #62).

[jlaehne]

@LMSC-NTappy would you find some time to review another file reader?

[LMSC-NTappy]

Absolutely!

If you don't mind I will do it this weekend :)

[LMSC-NTappy]

Do we care about XML vulnerabilities? I don't know much about them but maybe adding a note somewhere about this?

https://docs.python.org/3/library/xml.html#xml-vulnerabilities

(Well, just realized that many other readers make use of this module too...)

[LMSC-NTappy]

Great Job! Always nice to see new file formats being supported.

Looks pretty good to me, except that I don't like all the instance variables that get initialized randomly in the TrivistaTVFReader functions.

I suggest you move all those in the init() for clarity.

Cheers

Nicolas

[pietsjoh]

Thanks for the Review @LMSC-NTappy.

I agree that declaring attributes in __init__ gives a better overview of the instance variables. While thinking about setting all instance variables to None in __init__, I figured that the read_file() method could be moved to __init__ entirely. I also changed some methods such that they rather return values instead of setting instance variables. These two changes make it possible to set all instance variables directly in the constructor. This also emphasizes the importance of the order in which the methods are called and it makes their dependencies more clear.

Let me know what you think of this solution.

[LMSC-NTappy]

Let me know what you think of this solution.

Definitely better! Moving everything in the constructor is definitely going some steps further than asked but I don't see it as a problem :)

Someone maintaining this code 5-10 years from now will be thankful for that.