Simplify the parsing of kineticsFamilies = 'string' options from input file.

Less code, hopefully easier to understand.
Recommended reaction families read as a dictionary, not a function.

With this commit, the recommended.py file in 
RMG-database/input/kinetics/families/recommended.py
should just contain a dictionary, not a function call

recommendedFamilies = {
   '1,2-Birad_to_alkene': True,
   '1,2_Insertion': False,
  }

I'll make a corresponding commit in the RMG-database project.

Other changes:
Reduced code duplication, tidied up comments, and added more 
sanity checks on input, eg. we check that the list is all 
true or all false, not a mix, and we check that all the requested
families can be found in the database (before we just silently skipped them)
and check that all families in the database are listed in the recommended.py 
file as either True or False (in case we forget to add them).
Change the flow control when loading families list.

This is a small change, but it changes the indentation of 
a huge block of code so looks like a big one.
recommendedFamilies list (dict) stored in kinetics database attribute

The loading of the recommendation list has been moved to its own method
because it was getting complicated, and we want to be able to store this
more permanently, even if we aren't going to use it. This will allow us
to interrogate it, and, for example, to export the Java-style database with it.
(is this still going to be neccessarry?)
Export the recommended families list to RMG-Java style database.

Now that we have this data to hand, we may as well preserve it
and pass it along.
Make sure all the families listed in recommended.py are found in database.

Not just the ones listed as 'True.'
Unit test to make sure we get the right exception errors in loadFamilies.

An exercise that showed me how bad I am at making unit tests quickly.
Merge pull request #195 from connie/master

Change input file's behavior of loading families through `kineticFamilies` field, and various fixes.

There's a lot more error checking now, and the error checking is tested in a unit test!
Correct mispelling of 'Structures' in variable definition.
Moved QM methods one level above the PM3 class.

We will specify the structure method elsewhere in the code,
but scriptAttempts and maxAttempts will be used by all
methods, whether pm3, pm6, or other methods we decide to
add in the future.

In gaussian.py this includes the inputFileKeywords method,
while we detail the keywords under a specific class.

In mopac.py this includes the keywords, while we define the
inputFileKeywords method under a specific class.
Add pm6 calculations to the QMthermo module.

This enables pm6 calculations in this module, however
there needs to be a discussion about how we want this implemented.

Currently the default is to use PM3, and this has not been
changed. Should another option be added to the qm settings
where the user specifies method? Should a user be able to
use any choice of structure method and basis set?

QM is set up to reuse outputs from previous calculations,
however with added methods, a check has to occur to ensure
that the data from a previous run used the same level of theory.
Add the 'method' option to the qm settings.

Currently the only options are 'pm3' and 'pm6'. The
question is should we allow any method to be input.
Remove old inputFileKeywords from qm/gaussian.py

This was first made to be called from children classes,
however the method has now been brought into this class
so the repeated (but not implemented) method has to be
removed.
Move scriptAttempts and maxAttempts to parent class QMMolecule

We had the same properties/methods in both subclasses. I moved them 
to the parent class to reduce duplication.
Make MOPAC's PM3 and PM6 classes reuse code (and add PM7)

I think we went with a Class-based system of inheritance, so that you could override
arbitrary methods if necessary. Eg. you could have a Class B3LYP that would 
have to do bond additive corrections, or atomization energies, or something,
that would require additional methods and functions. 

For now, however, most methods differ just in one or two key words, so it seems
overkill. Should be extensible though...
Minor refactoring of mopac.py

Changing some if/else blocks to reduce nesting.
If we check the error condition (which will immediately return False) first,
then the rest doesn't need to be nested in an else block, and it's easier to
read from start to end and understand the flow control.
Minor refactoring of gaussian.py

Changing some if/else blocks to reduce nesting.
This is very much like the commit I just made in mopac.py
I wonder if some of this code duplication can be reduced...
Added @gmagoon's comments to the Gaussian pm3 keywords list.

In doing so I noticed that one of the sets of keywords was wrong 
(it was a duplicate of the line above it).
Added 'pm7' option to input file parsing for Mopac.

Also added some more exception handling for undefined methods.
1,3-Hexadiene input file now saves QMfiles in the output directory.

This makes it slower to run, because it won't re-use old files if you
delete the output folder between runs, but that makes it a better test,
and this is one of our Makefile test targets (`make eg2`).
`make eg2` will delete the output directory before running, so we now wipe
the slate clean of old QMfiles.