Distributed transpose logic
Remove unnecessary MatAdd and MatMul imports
added _ to eval_transpose in matexpr

Also rerouted ImmutableMatrix._eval_transpose to MatrixBase._eval_transpose
Decentralize Inverse logic
cleaned up imports
revert test to use == rather than .equals
Fixed issue 3323

Implemented the resolution proposed by Aaron in the discussion
of the issue on the google code website:
http://code.google.com/p/sympy/issues/detail?id=3323
expand_hint() functions now call _eval_expand_hint()
Add expand_power_exp(), for completion's sake
Remove unused definition line that fails in python 3.
Merge pull request #1423 from jrioux/tests

Fix python 3 tests
added another test for tr on density op of spin states
Make AlgebraicNumber more friendly as a subclass of Expr

Two things were done:

- AlgebraicNumber now correctly sets .args, so that expr.func(*expr.args)
  works for it.

- AlgebraicNumber.__eq__, which was doing fancy coercion, was deleted.  This
  means that things like AlgebraicNumber(sqrt(2)) == sqrt(2) will no longer
  work.  This does however fix a bug:

  >>> AlgebraicNumber(sqrt(2)) == None
  ...
  AttributeError: 'NoneType' object has no attribute 'is_AlgebraicNumber'

  It was unclear how to fix this bug in a general way with the coercion logic,
  and it was showing up with the refactoring of expand in methods derived from
  the super class Expr.

  This aligns with the standard of Basic objects that __eq__ performs exact
  structural comparison (unlike Poly objects, which often use coercion).

What was not done, but probably should be done, was a change to the printers,
so that AlgebraicNumber(sqrt(2)) does not look like sqrt(2) to users (who will
be even more confused now that AlgebraicNumber(sqrt(2)) == sqrt(2) doesn't
work any more.
style changes
Fix the docstring in expand_power_exp()
Import expand_power_exp() by default
Include the alias in the .args of AlgebraicNumber

This way, if you define the alias, operations on the expression containing the
number that rebuild the expression won't destroy it (e.g., expand).  The
downside is that you'll have AlgebraicNumber(sqrt(2), alias='alpha') !=
AlgebraicNumber(sqrt(2), alias='beta').
Special case Integral in polarify()

Now lift=True doesn't change the integration variables.
Refactor the expand framework

This cleans up a lot of the mess I started back in
2fea550d5618e6350d537a7d9b06f224751b1fdf.  Now, each expand hint is applied
only once.  Each _eval_expand_hint() method should call only
_eval_expand_hint, not expand(), and this it should only do if deep=True.
This should hopefully not only make expand() faster, but it should kill all
issue 3022 type recursion errors for once and all.

Previously, the expand() was a battle between getting everything expanded as
much as possible and avoiding infinite recursion.  The result was very hackish
and inconsistent code.

Classes no longer define no-op _eval_expand_* methods.  The only class that
defines such methods is Expr.  The rest should define an _eval_expand_* method
only if they has something to do for that hint.

In addition to this, I have now made if official that expand() supports
arbitrary hints (previously this worked, c.f., expand(commutator=True) from
the quantum module, but it was undocumented, and technically only worked by
mistake).

Because expand() hints are now only applied once, many expand() calls no
longer "go as far" as they used to.  For now, the solution is to call expand()
again.  In the future, expand() may be extended to be more intelligent about
when to reapply a hint, or when to apply them in a certain order to give
better expansion.

There are several test failures introduced by this commit that I have not yet
fixed.  Some of them are related to hash randomization, particularly the way
that expand hints are still applied in arbitrary order with it.  Fixing many
failures will not be possible until this is sorted out.  Other failures are
related to expand() not expanding as far as it used to.  These also will be
sorted out easier when expand() is changed to apply hints in a consistent
order.  Finally, a few errors I have not yet fixed because I am waiting on a
response from the community on the best course of action.  In particular, I am
not yet sure how to proceed with expand_trig() for sin(n*x) and cos(n*x) and
WGate, which currently does not work with expand() because it does not rebuild
correctly from its .args.

Finally, this commit does not include fixes to _eval_expand_complex.
Fix a docstring typo