Fix/protonation

[fgrunewald]

This PR fixes most perhaps all issues we have regarding neutral amino-acids and pronation states. It implements neutral protonated ASP and GLU as ASPP and GLUP as well as neutral LYS as LYN. Furthermore, it takes care of implementing the three HIS variants based on the naming scheme used in CHARMM and Amber. To that end the universal force-field is abandoned in favor of charmm. It always was charmm based anyways. In addition the amber force-field is implemented which allows using naming from the amber force-field family. This should cover most of the HIS naming schemes. Mapping PDBs directly from the PDB will still work the same way as previously with universal because the HIS residue still maps to HSD/HID respectively for the two force-field families. Abandoning universal has the advantage that usage should be more clear now. That is if someone maps an amber based PDB with names HIE/HID/HIP there will be the warning that these residues cannot be found. But simply changing the default -from charmm to -from amber solves the issue. It also makes clear that we don't support any other naming variants unlike universal that somehow suggested we could magically pick this up.

To Do

• [x] implement HIS Charmm
• [x] implement HIS Amber
• [x] check Amber names for neutral LYS, GLU, ASP
• [x] check that modifications would in principle work
• [x] add integration tests
• [x] make sure to add amino-acid names to all hidden variable definitions - [ ] add capped termini

Fixes

381 #323 #376 #417 #412 #395 #419

[pckroon]

Please rebase this PR on master and force push the result to resolve the merge conflicts

[fgrunewald]

@pckroon I propose we do the neutral terminals and terminal modifications in a separate PR. This one is already quite massive. I also only implemented the HIS-PROT for amber as a proof of concept. Later we can add all the others, but that's still a lot of changes to the data files.

[fgrunewald]

@pckroon I'm waiting for confirmation of the parameters but that could take a while

[fgrunewald]

@pckroon this looks some hypothesis stuff happening here?!

[pckroon]

Jup. In vermouth/tests/gmx/test_gro.py:410 hnp.scalar_dtypes() should probably be changed to e.g. st.choice(hnp.integer_dtypes, hnp.floating_dtypes, hnp.complex_number_dtypes), because well, we don't care about dates. Quicker fix might be to add an appropriate assume afterwards forbidding datetime objects. I'm ok with rerunning tests until hypothesis is happy though.