expand_hint() functions now call _eval_expand_hint()
Add expand_power_exp(), for completion's sake
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.
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
Modify the docscrape extensions to handle arbitrary headers

Still todo:  Make it render subheaders differently, e.g.,

Header
======

Subheader
---------
Fix expand() docstring to render correctly in Sphinx
Clarify a section in the expand() docstring
expand_hint() shortcut functions raise ValueError if _eval_expand_hint is not found
Fix Sphinx warnings in the expand docstring
In Expr._eval_expand_hint(), `not self.args` is a base case
Only rebuild the expression if one of the args was expanded
Merge branch 'master' into expand_refactor

Conflicts:
	sympy/core/function.py
Clean up the expand docstring
Add a note to the expand() docstring about the `modulus` meta-hint
permute method for Tr operator