`ufuncify` makes actual ufuncs

This is a rough pass at getting ufuncify to make actual ufuncs. It
works, but needs some cleanup, optimizations, tests, and documentation.
Ufuncify backends, code cleanups

- Brought back backends for F2Py and Cython. These now support
  broadcasting on all arguments, but mandate that the arguments be
  1-dimensional arrays of the same length.
- Default backend is the new `numpy` backend, which creates actual
  `ufunc`s.
- Code cleanups, improved docstrings, added tests.
Codewrappers infer/validate language from backend

In `autowrap` and `ufuncify`, the `language` kwarg now defaults to
`None`. In this state, the language is inferred from a lookup table of
backend -> tuple of languages, with the highest preference first. If the
language is specified, it is validated using this same lookup. This
prevents specifying `backend='f2py', language='c'`, and also allows the
user to only specify the backend to change behavior.

Also made some touchups to docstrings and tests.
Merge remote-tracking branch 'upstream/master' into ufuncify_improvements

Conflicts:
	sympy/utilities/autowrap.py
Cache calls to `ufuncify`

- `ufuncify` is not cached
- Small fix to `autowrap` docstring
Change ufuncify and autowrap signature

Kwargs now default None, not ().
`sympify` input to codeprinters

Ensures expression is hashable. Fixes issue #7980.
Add test for the issue 5673

closes #5673
Underscored the templates and a few lint fixes.
Merge pull request #6 from moorepants/jason-ufuncify

Underscored the templates and a few lint fixes.
Merge pull request #7929 from jcrist/ufuncify_improvements

`ufuncify` makes actual ufuncs
Merge pull request #8004 from jcrist/issue_7980

`sympify` input to codeprinters
Merge pull request #8007 from skirpichev/5673-fix

Add test for the issue 5673
NaN: remove erroneous docstring about inequality raising TypeError

This is an artifact of pull request #7776 and should not have been included.
Core: inequalities with NaN raise TypeError

NaN is indeterminant; for example the result of `0/0` could be
many values in the sense of limits (`5*x/x`, `x/x`, as `x` to zero).
By this interpretation, `3 < NaN` is not an valid comparison and
we raise the error.

Note this is different from the usual IEEE 754 Floating Point
system which regards all inequalities with NaN as false, using
the logic "3 is not determinably less than NaN".

Some tests in core/tests/test_numbers also updated.

This is discussed in issue #7773 and in pr #7776.
NaN: docstring update: doesn't exactly "represent" floating point nan

With changes to inequality behaviour, NaN behaves differently than
floating point nan.  We say "loosely related" instead.
meijerint: workaround NaN's in _check_antecedents

Inequality checks with NaN's used to be false.  Now they raise
TypeError.  This causes failures in meijerint.py's
`_check_antecedents`.  I've kludged it to get the previous behaviour
but its possible those NaN's are a symptom of a real issue.  Left
some comments and FIXME's in there for this.  Also labelled several
of the tests that hit the issue.