Fix lobsterin dict inheritance and treat \t in lobsterins correctly

[JaGeo]

Summary

Closes #3437 and #3438.
Inheritance of the dict was not carried out correctly. I have started here with inheriting from UserDict. We will add more tests to avoid similar issues in the future.

[JaGeo]

@naik-aakash , I have started with the fix. I will test methods like update, delete as well.

We could also directly implement a fix for reading lobsterins with \t

[naik-aakash]

Thanks! Thats great. So you will also fix the reading lobsterins with \t issue in this PR itself?

[JaGeo]

@naik-aakash You are invited to contribute to this PR. I am in the train today and I don't really expect to be able to work much on the remote connection 😅

[naik-aakash]

@naik-aakash You are invited to contribute to this PR. I am in the train today and I don't really expect to be able to work much on the remote connection 😅

Ah okay. Just got the invitation. Thank you 😄

[JaGeo]

I think I have now correctly implemented the inheritance from a UserDict. All standard functionalities work.

Things left to do:

• clarify how lobster reads cohpsteps (int, float): i.e., should we include a new category of lobster arguments?
• treat \t in lobsterins incluing whether Lobster can process them and test every different functionality

[naik-aakash]

I think treating \t is solved as well, have updated the existing test file to check the implementation and it seems to work fine .

I also tested if LOBSTER is able to read lobsterin files with \t as seperator between keyword and value (also at end of line). It does work fine

[JaGeo]

Update: LOBSTER can read cohpsteps as a float and integer. It will automatically round to the next larger integer independent on whether it is a float or an integer (in versions 4.1.0 and 5.0.0). I think it doesn't really matter that we print a float... Also, I think this behavior of LOBSTER is a bit unexpected (instead of 308, Lobster uses 309).

[JaGeo]

@janosh , I think this would be ready for review in case you have time.