MULTIBATH constructor difficult to use

[pultar]

The constructor of MULTIBATH is not very convenient to use and requires initialization of many variables. Some of these variables are often identical (like COMBATH and IRBATH) or can be derived (like DOFSET):

def __init__(self, ALGORITHM: int=0, NBATHS: int=0, TEMP0: List[float]=[], TAU: List[float]=[], DOFSET: int=0, LAST: List[int]=[],
             COMBATH: List[int]=[],
             IRBATH: List[int]=[], NUM: int = None, content=None):

Initialization happens like that:

ALGORITHM = 1 # Nosé-Hoover scheme
NBATHS = len(self._temperature_baths)
TEMP0 = [self.temperature] * NBATHS
TAU = [0.1] * NBATHS
DOFSET = len(self._temperature_baths)
LAST = list(self._temperature_baths.keys())
COMBATH = list(self._temperature_baths.values())
IRBATH = list(self._temperature_baths.values())
self._system.imd.add_block(
    block=MULTIBATH(ALGORITHM, NBATHS, TEMP0, TAU, DOFSET, LAST, COMBATH, IRBATH)
)

How about we take an approach as taken here? For example, T and TAU can be a list or floats (as they are often the same for several baths). Also, I like the dictionary approach for last_atoms_bath.

def adapt_multibath(self, last_atoms_bath: Dict[int, int], algorithm: int = None, num: int = None, T: (float, List[float]) = None,
                        TAU: float = None) -> None:

Ideally, we would implement this in a way that does not break things.

[MTLehner]

I like this idea. Convenience functions are always useful!

[MTLehner]

@pultar does this need to be in release3? The way I see it this is not a major restructuring, but rather a addition we can add later if actually needed