Change preview to use BytesIO instead of StringIO

This fixes it to work in Python 3. Since BytesIO is available in Python 2.6,
the use of StringIO has been deprecated. See
https://code.google.com/p/sympy/issues/detail?id=3984.

This fixes, in particular, init_printing(use_latex='png') in Python 3.
Merge branch 'master' into preview_bytesio

Conflicts:
	sympy/interactive/printing.py
Make degree(0) == -oo in the polys

Previously, degree(0) was -1. This makes sense for the dense representation,
because then one can use degree in place of len(f) - 1, but outside of that,
it makes little sense. In particular, the very important formula regarding
degree, deg(f*g) == deg(f) + deg(g), does not hold unless deg(0) == -oo.
Therefore, any code that does arithmetic on a degree and then makes a
comparison against it (like "if degree(f) - 1 > 0"), such as some code in the
Risch algorithm) was previously for 0 but generally correct now.

Fixing this just means being more careful about when you mean degree(f) and
when you mean len(f) - 1 in the dense representation algorithms.  Another
argument for this is that the change in the sparse code required no additional
changes anywhere; apparently the degree does not correspond to any natural
quantity in the sparse representation.
Fix typo
Fix some additional issues caused by degree(0) == -oo
Add evaluate=False to sympify
Add docstring for sympify(, evaluate=False)
sympify(evaluate=False) denests Add and Mul
integrals.transforms: Fix for issue 2486
Added numpy ndarray to TensorIndexType and TensExpr
minor improvements
Fixed canon_bp and sorting for valued tensors
test added for issue 2486
Make the doctest for Interval.subset actually test subset
removed trailing whitespace
Catch ValueError in _eval_is_positive/negative

See issue 4066. Sometimes evalf raises ValueError, such as at poles of the
gamma function.
Don't do any simplification in is_constant when simplify=False
Remove some nondeterminism from meijerint
Use "not expr.args", not "isinstance(expr, Atom)" in simplify
Add Basic types for True and False (issue 2531)

This commit implements the following changes:

- Adds BooleanTrue and BooleanFalse in sympy.logic.boolalg.  These classes are
  singletonized, and the instances can be accessed by S.true and S.false (note
  that True and False are keywords in Python 3, so S.True and S.False is not
  possible).

- Makes sympify(True) and sympify(False) return S.true and S.false.

- This previous change resulted in a ripple effect across all parts of SymPy.
  In particular, now all the boolean functions like And and Or return S.true
  and S.false.  This required two major change: many doctests had to change
  "True" to "true", and many pieces of code throughout SymPy like "if x is
  True" had to be changed to "if x == True" (S.true == True holds). The
  meijerint module in particular had many instances of this, due to its
  extensive use of convergence conditions, and in many cases, the wrong one
  resulted in incorrect program logic that produced wrong results.

- Piecewise now uses S.true instead of a dummy for the otherwise condition.

- cancel() had to be modified to check for S.true and S.false, and exit in
  that case.  This is because simplify() calls cancel() recursively on the
  args of Piecewise.  Doing this "right" is left as a TODO.

- As part of the cleanup of the boolalg classes, all docstrings were moved
  from the eval method to the class, where they will be found by help().

- Confusing parts of the docstrings of And and Or about & and | were cleaned
  up, and documentation written for all the classes with operator counterparts
  alerting the user to the gotchas of using the operators with the builtin
  bool types instead of S.true and S.false.

- Extensive tests were added to ensure the boolalg classes return S.true and
  S.false and not bool, and that S.true and S.false behave as they should with
  respect to True and False.

- The relevant printers have been updated for S.true and S.false, including
  the lambdarepr printer, so that lambdify([], S.true)() gives True.  For the
  LaTeX and pretty printers, it just prints "true".

- An unrelated change that slipped in: checksol passes simplify=False to
  is_constant when minimal=True.  This is used in the constructor of
  Piecewise, so should remain as fast as possible.

There is a comment in boolalg.py describing what I think the general policy
should be regarding when to use True/False and when to use S.true/S.false
throughout SymPy.  The comment is worth reading for anyone who is concerned
about the issue, but it's worth reiterating the main rule of thumb: "If the
boolean in question can be replaced by an arbitrary symbolic Boolean, like
Or(x, y) or x > 1, use S.true. Otherwise, use True."

In this commit, S.true is used wherever it is converted automatically by
sympify (i.e., as an element of .args, or as the result of something like
Not(x).subs(x, False)).

The main annoyance of this commit is that "x is True" (as opposed to "x ==
True") will be wrong if the value of x can be S.true.  One has to think
carefully whether the value of x could ever result from a symbolic expression.
When in doubt, use ==.  One also needs to use "x in [True, False]" instead of
"isinstance(x, bool)" (BooleanTrue and BooleanFalse hash to the same value as
their bool counterparts, so set or dictionary containment will also work, but
they do not subclass from bool).  Subclassing from bool is perhaps not
desired, as, for instance, S.true is not an integer (in particular, the
bitwise operations ~, >>, <<, &, |, and ^ all act logically, not as they do on
int(1)).