Made ordering of improper torsions more consistent.  Also fixed a bug related to Drude particles.
Fixed an error in the computation of Drude screening force
Created option so virtual sites can share the exclusions of their parent
Changed definition of polarizability to match CHARMM
Created XML file for CHARMM polarizable force field
Added CHARMM polarizable force field to the list of force fields in the manual
Fixed some incorrect test cases.
Trivial change to force travis to rerun the tests
Merge remote-tracking branch 'origin/master' into charmm
Depressing compromise to make the ordering of atoms in improper torsions as consistent as possible with both AMBER and CHARMM
Merge pull request #531 from peastman/charmm

Implemented CHARMM polarizable force field
Revert to older Travis-CI testing framework so we can separate testing from conda dev builds.
Merge pull request #533 from jchodera/revert-travis-ci

Revert to older Travis-CI testing framework to separate testing from conda dev builds
Fixed bug when running on a CPU device
Merge pull request #535 from peastman/master

Fixed bug when running on a CPU device
- Some minor cleanups and simplifications in the Amber prmtop parser.
- Convert coordinates, velocities, and box vectors into Vec3 objects to avoid a
  subtle bug in the units module with respect to silently modifying mutable
  collections in-place when converting to a new set of units.
Merge pull request #536 from swails/fix_inpcrd_units

Convert AmberInpcrdFile data structures from lists to Vec3
Fixed a bug in unit conversion for sequences
Merge pull request #538 from peastman/master

Fixed a bug in unit conversion for sequences
Add an explicit (shallow) copy constructor for CustomNonbondedForce. This fixes
segfaults when you use the long-range dispersion correction with the
CustomNonbondedForce if the force uses TabulatedFunction objects. Basically, it
prevents the copy from taking ownership (and deleting) the functions in its
destructor.

The use cases for CustomNonbondedForce copying currently is to recompute the
long-range prefactor if the parameters change (so the CustomNonbondedForceImpl
kernels need a copy of the Force object). Doing a full (deep) copy would be a
bit slower (although would only need to be paid once for each
CustomNonbondedForce object being used).