Moltemplate

The order of the atom types listed in the "dreiding.lt" file has been modified to (hopefully) make sure that LAMMPS does not get confused regarding which atoms are hydrogen-bond donors and acceptors. This is an attempt to address issue 46.

I *think* this is working now. However, if you use hydrogen bonds with DREIDING, then please double-check the "system.in.settings" files created by moltemplate.sh, and check each "pair_coeff" command containing the text "hbond/dreiding/lj". Make sure that the atom types are listed in the correct order, with donor atom types listed before acceptor atoms. Before doing this, I suggest running [cleanup_moltemplate.sh](https://github.com/jewettaij/moltemplate/blob/master/doc/doc_cleanup_moltemplate.md#cleanup_moltemplatesh) first. *(Otherwise the number of pair_coeff commands in the "system.in.settings" file might be too large to check by hand. The "cleanup_moltemplate.sh" program should work without issue with DREIDING simulation files as long as your main LT file is named "system.lt". Just type "cleanup_moltemplate.sh" into the terminal after running moltemplate.sh. In the future, when "dreiding.lt" is debugged, this extra effort won't be necessary.)*

Many thanks to Aileen Huang (ahuang5student.gn.k12.ny.us) for reporting this issue!

-The MARTINI force field implementation has been incorrect for years, apparently. *(It might still be, but at least MARTINI simulations now show no visually obvious signs of failure.)* We obtained the MARTINI force field parameters from the EMC program instead of the original source (the cgmartini.nl web site). I am still not positive that the MARTINI force field parameters provided by EMC are compatible with the most recent MARTINI files. (If not, please let me know.) Consequently, it might be necessary to reimplement MARTINI using the original source files in the future.
-The "drymartini.lt" force field file was also added (although it has not yet been tested.)
-I fixed a (hopefully) minor problem in the OPLSAA implementation. I was using a non-bonded distance cutoff that may have been too short (10 Angstroms instead of 11). (The 1996 OPLSAA paper used an 11 Angstrom cutoff for most interactions.) Hopefully this change not significantly effect most simulation results. *(Note to users: We do make mistakes, so it's never a bad idea to double-check the global settings in the force-field files we provide.)*
-Finally, I added some messages that tell users what papers to cite when they run moltemplate. (Hopefully this is not too annoying.)

moltemplate.sh only switches to python" or "python2" if "python3" is not available.

Also: The installation instructions in the README.md file have also been elaborated to help users with python installation difficulty.

I fixed the issue that was introduced in version v2.19.4. Now moltemplate.sh will warn you if you try to write to both "system.in.settings" as well as "In Settings". I also now print a message asking users to cite the moltemplate paper.

Normally, moltemplate files contain *write_once()* and *write()* commands that append text to files with names like "In Settings" or "In Init". Later, moltemplate will automatically convert the names of these files to "system.in.settings" and "system.in.init". After this patch, users can now write to the "system.in.settings" and "system.in.init" files directly (instead of "In Settings", and "In Init", and other files that begin with "In "). Moltemplate.sh will now check these files as well when it checks to make sure that all of the necessary coeffs have been defined.

Known bug
If the user writes to "system.in.settings" and *also* writes to "In Settings", the text in "In Settings" will erase the text in "system.in.settings" (instead of appending the two files together). This is an easy to fix, but I don't have time to get to it now. I'll post another update soon.

Fixed a bug in the lexer preventing escape characters ('\\') from being interpreted correctly when preceding curly brackets ('\\{') or other escape characters ('\\\\'). This may have been impacting ATB database users and MOLC users. Hopefully the ATB files work well again with moltemplate now. (And hopefully this fix doesn't break anything else.)
Thanks to Otello M. Roscioni (MaterialX LTD) for discovering the bug!