Added 'recommended' attribute to KineticsDepository's constructor
Set default 'recommended=True' for rules imported from RMG-Java
Minor tweak to KineticsLibrary.saveOld.writeArrhenius

Prevented possible lack of whitespace between Arrhenius parameters,
per recommendation by @rwest in edf92cff90d4a0e9a82e9ecbb11113dc53dab8f4.
Added handling of reverse reaction family names

These would otherwise be lost upon importing from Java
Fix for StatesGroups saving in Database.saveOld

RMG-Java does not require a frequencies_groups/Library.txt file to
operate, but errors are raised upon importing to Py if this file is
not found. This check prevents the placeholder from being discarded.
Fix to StatesDatabase.saveOld

Prevents unnecessary blank 'frequencies_libraries' paths from
being created upon database exporting
Do not fail when parent directories need to be created.
Added handling for absent KineticsFamily.reverse attribute

The reverse attribute, which stores the name of a reaction family's
opposite, was added in f566b2526a7523504a609a45367bc917d3b7fb9d, but the RMG-database branch that
actually introduces this attribute to each family is not yet ready
to be pulled in. Until then, this except block allows families to
load without error.
Fix to allow blank rules depositories

In light of my effort to migrate rate rules back to their original
NIST entries (and, eventually, into training rates), it is now
possible that a family can be entirely devoid of rate rules. This
tweak prevents crashing upon trying to determine the appropriate
index for training entries to be added back to these blank rule
depositories.
Tweaks to ThirdBody efficiency writing in KineticsLibrary.saveOld

See GreenGroup/RMG-database#11
Give Chebyshev objects units when extracting from chemkin file.
Generate reverse rate coefficients for Chebyshev, PDepArrhenius, MultiKinetics.

Expanded the generateReverseRateCoefficient function to accomodate more
types of kinetics.
Moved physical constants to new rmgpy.constants module.

This gives users the option of importing the constants separately from
the Quantity functionality. The constants have also been made into
module-level variables instead of attributes of an otherwise-needless
class. The same globals() trick allows the defined module-level constants
to be accessible from both Python and Cython contexts; when cimported,
the C version of the constants will be made available to Cython modules.
Updated import statements to find new rmgpy.constants module.

Many of the imports of the rmgpy.quantity module only asked for one or
the other of the Quantity class or the constants object, so there seems
to be at least a small amount of sense in decoupling them. Still, many
other imports wanted both anyway, so this may just be a cosmetic change.
Improved classes for representing physical quantities.

There are now separate classes for representing scalar and higher-order
quantities, aptly named ScalarQuantity and ArrayQuantity, respectively.
For the most part, you don't need to use these directly, though; instead,
use the Quantity() function, which returns either a ScalarQuantity or
ArrayQuantity object based on the input value, units, and uncertainty.

The value attribute of both ScalarQuantity and ArrayQuantity has been
changed to a property that returns the value of the quantity in the
given units. Previously it had stored the value in the SI equivalent to
facilitate speedy computations, which worked but was rather awkward to
explain to people. What was the value attribute is now called value_si
to emphasize that it stores the value in the SI equivalent. This is
still available directly for speedy computations.

I've also revamped the unit tests accordingly.
Now using ScalarQuantity, ArrayQuantity, and value_si throughout codebase.

I've tested some of the changes using the unit tests that were previously
working, and almost all of them still pass. There are a few exceptions
that I'm ignoring for now because I think they will be addressed as part
of future commits anyway.
Moved rmgpy.constants unit tests to rmgpy package.

The motivation here is to have the unit tests live in modules alongside
the modules they test. This makes them more visible when editing the
codebase, which encourages developers to keep them up to date. We can
also use nose to automatically search and run the unit tests, perhaps as
a post-commit hook to further prevent the tests from becoming stale.
Added functions for validation of various unit types.

One thing that's been missing from our handling of physical quantities
has been the enforcing of unit types. For example, there is nothing
currently stopping someone from storing a moment of inertia in units of
cm^-1, which would lead to crazy rotational and torsional partition
functions, etc. This commit provides the UnitType class, a functor
(a function with associated metadata) for creating ScalarQuantity or
ArrayQuantity objects of a unit type. Several module-level instances of
UnitType are also defined, e.g. Inertia for moments of inertia.

The UnitType objects also give us the opportunity to handle unusual
units, e.g. frequencies in units of cm^-1 or K instead of s^-1, etc.
Note that RateCoefficient is currently implemented as a special case, as
these can have different units depending on the reaction order.

Also note that all energies, enthalpies, free energies, entropies, heat
capacities, concentrations, fluxes, and rate coefficients are treated as
intensive. This means that you must use mol or molecule for these. All
other unit types are extensive. A special case is added for mass to
convert e.g. g/mol to amu.

There are a large number of unit tests to ensure that the unit types
are acting as intended, as there are several edge cases.