less flattening and less autosimplification

* sympy/core/add.py
    - in the 2-arg optimization
        o if an Add is encountered in the 2-arg optimaztion code
          let the main loop handle denesting of it; a test was added for this
        o don't expand the 2-arg mul
    - in the main flattening routine, don't evaluate unevaluated powers
      or Mul so now
        x + 2**3 does not become x + 8; test added to test_arit.py
        x + 2*(x + 1) does not become 3*x + 2; test added to test_arit.py

* sympy/core/expr.py

    - logs no longer extract perfect powers so this can lead to the
      need of expand_log being applied more than once; a test has been added

* sympy/core/mul.py

    - in the 2-arg optimization (as for Add), if an unevaluated Mul
      is encountered, let the main flattening loop handle it; a test was added

    - in the main flattening loop
        o don't evaluate unevaluated powers, so 3*2**3 will not become 24
          at that portion of the code (it happens later -- XXX fix that)
        o removed the comment about a Rational power on I being a sign of
          being unevaluated; that could be removed from there but see the
          XXX above since process of base/exponent pairs may handle it
          lower in the flattening code.

* sympy/core/tests/test_arit.py

    tests described above were added; test that no longer conforms to
    criteria was changed

* sympy/core/tests/test_expand.py

    a situation where multiple expansion of log being necessary was added

* sympy/functions/combinatorial/numbers.py

    test modified for new log behavior

* sympy/functions/combinatorial/tests/test_comb_numbers.py

    test modified for new log behavior

* sympy/functions/elementary/exponential.py

    - the condition raising a value error was removed as that is handled
      farther up
    - perfect powers are no longer handled by log so log(8) not log(2**3)
      becomes 3*log(2) unless expand_log is applied; the handling was moved
      to _eval_expand_log

    - the extraction of powers of the designated base are processed, however,
      so log(8, 2) becomes 3.

* sympy/functions/elementary/tests/test_exponential.py

    test changed to equivalent forms

* sympy/integrals/tests/test_integrals.py

    test changed to equivalent forms

* sympy/integrals/tests/test_transforms.py

    wrapped a long test

* sympy/physics/quantum/gate.py

    docstring edits

* sympy/physics/quantum/matrixutils.py

    In quantum an unevaluate 1/sqrt(2) is used; this used to be processed in
    Mul.flatten. Now it is not, but tests relied on it being processed and
    actually look better if it is, so a touchup function was added to the
    utilities to handle it. It is written to re-evaluate any power with
    an integer base and rational exponent since 1/sqrt(2) = 2**(-1/2)

* sympy/physics/quantum/represent.py

    the _touch_Pow cleanup is applied to places where tests failed without it

* sympy/physics/quantum/tests/test_gate.py

    usually the 1/sqrt is evaluated; in this case it wasn't so the test
    was re-written for the new behavior. I'm not sure it's worth special
    casing the situation where the sqrt(2) does not appear in the denominator
    of a Mul, but that could be done.

* sympy/polys/polyroots.py

    polys can behave a little strangely with Add generators. The
    singular_value test in test_matrices.py will generate an expression
    containing something like sqrt(x**2/2 - x**2/2 + 1) without this change.

* sympy/simplify/simplify.py

    _denest_pow must explicitly expand logs in order for things like
    log(16) to become 4*log(2)

    to make the code self-correcting for a workaround, an assertion was
    placed in the code that will test the conditions of the workaround.

    the changes that were made in this PR triggered the assertion failure
    so consolidation of c_powers is now done...and that's why assertions
    are useful! It would have been fairly tricky to find where the
    error was occuring if that assertion were not there.

* sympy/simplify/tests/test_simplify.py

    radsimp is apparently using an unevaluated Mul and that could be
    changed, but for now I just modified the test that failed because
    the unevaluated Mul is not longer denested. expand could also be used
    to denest it.

* sympy/solvers/solvers.py

    modify test for new log behavior

* sympy/solvers/tests/test_ode.py

    XXX two tests giving a key error were commented out for now and
    should be fixed.

* sympy/solvers/tests/test_polysys.py

    the touch-up function in polyroots returns an expanded Mul if it
    has a lower count_ops than the factored form and that shows up here
    in this changed test.