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)).
Remove unnecessary logic

S.true and S.false both compare equal to and hash to the same value as True
and False, respectively, so they are considered to be the exact same thing by
sets.