Fixed bug in FAME inverse Laplace transform method for n > 0.

There is a small possibility that, given an unlucky set of Arrhenius
parameters and barrier height, that the numerator in the ILT expression
for k(E) when n > 0 could have a negative value at the first reactive
energy grain.

Closes #247.
Merge branch 'master'
Added handling of n < 0 to FAME inverse Laplace transform method.

The implementation is not defined for negative temperature exponents.
When they occur, we simply move the T^n piece into the A factor (done
separately at each T). This is a crude but necessary approximation.
Better way of choosing direction to return k(T,P) values from FAME.

The previous approach tried to choose the direction with the larger
k(T,P) values. However, this might differ depending on the temperature,
and is certainly not simple to predict a priori. The new method uses the
ground-state energies of the reactants and products to decide, which is
much more straightforward.
Don't check T and P range if not defined.

The TMIN, TMAX, PMIN and PMAX are static variables belonging to the entire
class of PDepRateConstants, and are only defined if running with PDep on.
If running with PDep off, there are no validity limits, and yet we still
may want to evaluate PDepRateConstants coming from a seed mechanism or PRL.
In this case, we just skip (or always pass) the validity test.

Closes #242 and #253
More helpful error message when using a forbidden structure in a seed mechanism.

It now advises you to add it to a Thermo Library.
Remove a couple of unnecessary comments.
Added an advisory note to kinetics libraries documentation.

The advice is to add forbidden molecules to a primary thermodynamics library.
Along with the improved error message in 086c9a71d0dc64b9e00a64eeacf5c76053cded49 this closes #249
Added an empty pdepreactions.txt file to Methylformate reaction library.

This is needed, even though it is empty.
Closes #256
Modifying the GATPFit program to accept a series of inputs rather than one at a time.
Make GATPFit compile with gfortran.

I reverted one of the changes in the previous commit. I like the change, it looks nice,
but I think it uses something in the Fortran 2003 standard, and this file is in F77 format,
and I couldn't for the life of me get it to compile in gfortran. This compiles, and for me, works.
GATPfit is now a long running process that listens for input as opposed to launching everytime. The fortran program was modified to loop in the last commit.
Change message when GATPFit has finished one input.
Some code tidying in jing/chem/GATPFit.java
Merge branch 'avoidfork' to avoid frequent forks when launching GATPFit

The idea is to fork and run the GATPFit process only once, and have it
continually listen for input, rather than relaunching a new process every
time it is required. Aparrently this saves a lot of time, because it happens
very frequently (once per edge species).

If we can pull something like this off for ALL the external binaries
(FAME, DASSL, Frankie) then we can solve issue #54 and halve our memory
requirements!  I think the others will have less of an impact on speed, because
they are called less often than GATPFit, but may be worth trying for the
memory alone.

Many thanks to Ramanan Sankaran <sankaranr@ornl.gov> for the suggestions and
commits on this branch.
Revert "Merge branch 'avoidfork' to avoid frequent forks when launching GATPFit"

This reverts commit 4413bae5834e3b947d174e07fb99c3e4d51cedcb, reversing
changes made to 61f227ff6f9ee3c1a4fb5a96be66d2235c6a6704.

It doesn't yet work on some linux servers (see issue #257) so I'm taking
it off the 'master' branch. Please help fix it by tracking my 'avoidfork' branch.

NB. BEFORE Re-merging the "avoidfork" branch again, you will have to revert this revert!
i.e. 'git revert ___' (whatever this commit's hash is).
then 'git merge avoidfork'

See explanaition from Linus at
http://code.google.com/p/git-core/source/browse/Documentation/howto/revert-a-faulty-merge.txt
removed debugging lines for #239

a fix has been committed for #239 and the issue does not seem to have recurred over the last few months of use