Remove input layer in topoaa module.

[joaomcteixeira]

@amjjbonvin one of the things we discussed in today's IVRESSE meeting was the possibility to remove the input layer from the topoaa module such that we have only mol1, mol2, etc, directly in the top layer of the config file. As you can see from the changes in this PR, removing the input layer adds no burden to the Python API (see changes in the topoaa/__init__.py file. I have these changes already prepared for the #274 if you accept them.

@sverhoeven

[joaomcteixeira]

Another thing we could consider is to remove the mol beyond 1. These are basically the same with the exception that prot_segid is a cycle over the alphabet. Can't we remove mol2 to mol20? and make that an expandable engine as well? The user could define the parameters in the config file for mol3 if needed without mol3 being defined in the topoaa/defaults.cfg file.

[amjjbonvin]

We could indeed make the mol parameters expandable. I would however keep the prot_segid ones, since now a user does not need per se to define those. If we remove them then this must be defined in the user config file. Or the python code must automatically define those incrementing the chainIDs in case they are not defined by the user.

[amjjbonvin]

So no need for topoaa in the param name here? Will be confusing to users since our example config files do use the topoaa.molX naming. To me the default.cfg file of a module shows me all the possible parameters and the way to define those. I think we already discussed that before since we have the same inconsistency before these changes.

[joaomcteixeira]

It's a different thing. In the defaults.cfg we use [mol1] and not [topoaa.mol1] because the default.cfg itself is the topoaa module, while the user config has several modules so we need to define the [topoaa] layer. Keep in mind that the user will never access the defaults.cfg per se. We will always provide a script or an API that translates the defaults.cfg to what the user needs. I see in #274 I've create an haddock3-cfg CLI for that purpose. Actually, after #274 is merged the concern you raised in your comment get's solved because we move from the defaults from cfg to yml.

[joaomcteixeira]

Accepting. Good addition 👍