Started work on Linearizer Class

Implemented routine for constraints on position and velocity.
Unsure if it will work if either are missing, most likely will need
to add control flow for this. The API is also complicated, and will
be simplified as more code is ported over.

Also added one test for the new linearize routine. Based off of
the example in Luke and Gilbert's paper. As more functionality is
added to the linearization routine, the work done in this test
will get smaller. Still need to add more tests from the examples
I worked out last week.
Lots of work on linearization methods

- Added `to_linearizer` method to KanesMethod class. This returns
an instance of Linearizer with all information needed for the class.

- Made 1 meaninful test with the rolling disc test case. The other
two tests aren't finished yet.

- _subs_keep_derivs was written. This substitutes in values for symbols,
but keeps the derivatives of the from being substituted out.
Assorted fixes in Linearizer Class

- Forgot to multiply A and B by P^T when outputting just the
A and B matrices. Fixed.

- Added an eigenvalues test in the rollingdisc test

- Formatting and code quality fixes
Added support for no f_c/f_v in Linearizer

The Linearizer class now supports linearization for systems with
 - Both configuration and motion constraints
 - Only configuration constraints
 - Only velocity constraints
 - No constraints

Added a test for no constraints. Still need tests for just f_c and
just f_v. Added rough beginnings of `linearize` class method for
KanesMethod. The interface still needs to be decided on.
Generalized Linearization Routine

The following changes were made to the Linearizer Class:

1.) Now accepts if q, u, or any of the f_# generalized terms
are empty matrices. Linearization proceeds as it should.

2.) Broke the linearization process into a couple "private"
class methods. The ones done so far only need to be run once
upon initialization. This should save calculation time if the
user intends to do multiple linearizations about different
operating points.
Changes to Linearizer and Related tests

- All tests now are valid and pass
- Improved doc strings, still needs more work
- Modified tests for KanesMethod to use the new functionality

Now have the same functionality as before with linearizing
KanesMethod objects, but code is more generalized and easily
extended.
Code cleanup, pep8 fixes, docstrings edits

- Code cleanup with flake8 for pep8 fixes in new code
- Edits to docstrings
- Fixed doc tests
Fix for python 2.6 - dict comprehension changed

Using a generator expression and the dict() constructor now.
Docstring fixes, and small bug fix

- Fixed the docstring issues found in code review.
- Also, M_uqd = f_3.jacobian(qd), not f_2.jacobian(qd) as was
written previously.
Added deprecation warning for old linearize method

Deprecation cycle plan:
- User must use kwarg `new_method=True` to use the new
functionality.
- If the kwarg is absent or false, the old method is used and a
SymPyDeprecationWarning is thrown.
- After the next release, the old method will be removed, and the
need for this kwarg also removed.
Code cleanup, major docstring edits

Fixed lots of little things. Major edits to the docstrings to fit
the numpydoc format. Some code refactoring as well. Removed the
_general_form method in KanesMethod, as it was small, and fit
better with to_linearizer. Added linearize.py to __init__.py.
Changed linearize interface for op_points

Now have one kwarg instead of several. `op_point` can be either
a single dict, or an iterable of dicts. Results in simpler
interface, and we were combining them all internally later
anyway.
Changed Linearizer to use LUsolve instead of inv

Now calculates A = P.T*M.LUsolve(Amat), insead of
A = P.T*M.inv()*Amat. This results in a significant decrease in
calculation time. `inv` was replaced with this `LUsolve` method in
all locations in Linearizer.
Added kwarg `simplify` to Linearizer class

Allows for optional simplification of return values before
return from linearize call. Defaults to True.

Several different methods of simplification were tested, and all
were slower than just calling simplify on the matrices. `trigsimp`
resulted in the same thing as `simplify`, but took 5 times longer.
Currently, calling simplify seems to be the best method.
Changed `simplify` kwarg to default False

Simplify can be computationally intensive, better to have the user
opt in intentionally.
Merge pull request #7581 from jcrist/LinearizeClass

Linearize class