Moltemplate

Fixed bug 86 which prevented cleanup_moltemplate.sh from working whenever "moltemplate" was installed using pip or pip3.

*(This bug did not effect the small number of users like me who [install moltemplate by other means](https://github.com/jewettaij/moltemplate/blob/master/INSTALL.md#installation-method-2-editing-bashrc).)*

All credit belongs to github user **PhnRvTjN** (Phani Ravi Teja Nunna) for solving the bug, and to github user **yurivict** for reporting the bug!

I replaced

!/usr/bin/env python

with

!/usr/bin/env python3

...everywhere.

This means users are no longer required to use "python" instead of "python3" when trying to run .py executable files directly from the shell (such as mol22lt.py, ltemplify.py, and genpoly_lt.py). This will enable most users to be able to invoke these python programs directly by their names, without having to predicate them with "python3".

Comment:
I'm sorry I didn't make this change earlier. I've been using anaconda python for a long time, and anaconda automatically adds a link from "python3" to "python", so that users can type "python" instead of "python3". I didn't realize that for most users, "python" isn't even defined.

When the LT file is not named "system.lt":
- generated "run.in.EXAMPLE" files are renamed to avoid file name collisions (so that users can run moltemplate.sh on multiple LT files in the same directory)
- The "cleanup_moltemplate.sh" script can also handle files with names that do not begin with "system" (by including the "-base" argument).
- The "cleanup_moltemplate.sh" script no longer assumes that the python interpreter is named "python". (It could be named "python" or "python2".)

1) I fixed an edge-case bug causing "cleanup_moltemplate.sh" to fail without printing out an error message. This would happen whenever the user ran moltemplate.sh on a file ***not*** named "system.lt", and then attempted to run "cleanup_moltemplate.sh" afterwards. (This is a situation that "cleanup_moltemplate.sh" does not handle gracefully.) I did not fix this limitation. But now whenever a user does this, it prints out a detailed error message explaining how to get around this limitation.
2) I fixed some serious mistakes in the "spc_oplsaa.lt" and "tip3p_oplsaa.lt" files (for the SPC and TIP3P water models). Thanks to github user feifzhou for pointing them out!

The atom:hw and atom:ow atom types in "gaff2.lt" now have been given epsilon and sigma parameters (of 0.0 and 1.0). These parameters are not correct, but at least users who don't need these atom types and want to use "gaff2.lt" will be able to do so (without LAMMPS complaining about missing pair_coeffs).

Similarly the *amber2lt.py* program will now supply default epsilon and sigma parameters (of 0.0 and 1.0) for atoms when this information is lacking in the FRCMOD or DAT file containing the force-field parameters (such as "gaff2.dat").

The *amber2lt.py* program accepts a slightly wider range of FRCMOD file formats.

Thanks to Karteek Bejegam and Jonathan Campeggio for their debugging help and suggestions!

The newly added *amber2lt.py* program converts force-field files used by and created by AmberTools (such as FRCMOD and DAT files) into moltemplate (LT) format. The "gaff.lt" and "gaff2.lt" files were created with this program. Now users can use this tool as well with their own custom FRCMOD files.

The *amber2lt.py* script replaces amberparm_*.py files and amber*.sh scripts that were used before. (Those scripts were buggy and undocumented.)