Improved simplification behavior

Summary:
This is the end of the "simplified means it must be fully expanded" behavior.
We now approach each step of simplification one at a time, and only persist
the results of a given step if it helps lead to a simpler expresson/equation.
More specifically: If collecting like terms, etc. doesn't do anything after a
transform step (either factoring or expanding), rollback the transform.

e.g. `2x+2y` and `2(x+y)` are now considered equally simplified.

Key to being able to make this change is being sure that `collect()` is a noop
if there is truly nothing to do. However, we had some behavior where some
quantities could exist in one of two representations and `collect()` could
change one to the other. Specifically, 1/2 could either be `Rational(1,2)` or
`Pow(Int(2), Int(-1))`. We'd always parse input as `Rational(1,2)`, but would
sometimes generate the other representation during some processing step.
I went down a bit of a rabbit hole investigating what it would be like if we
used the `Pow` representation everywhere, but ended up standardizing on
`Rational` (more annoying to generate, but easier to work with).

Fixes T3053 and T3239.

Test Plan: See new and modified test cases in `test.html`

Reviewers: aria

Reviewed By: aria

Maniphest Tasks: T3053

Differential Revision: http://phabricator.khanacademy.org/D13640
Add support for latex and unicode division operators

Test Plan: test.html

Reviewers: joel

Differential Revision: http://phabricator.khanacademy.org/D13735