BUG: #2408, Fix f2py Python 3 error message string bug.

The original was generating an exception message and, after aliasing,
calling PyBytes_AsString on a unicode string -> error. It was also
leaking references, although that probably didn't matter in context.

The fix here is on the cheap side, just use a C string for the message
without including the extra information about the erroneous type that
led to the exception.

No test, I don't know how to evoke this error.

Closes #2408.

Use PyUString_FromStringAndSize defined in npy_3kcompat instead. Not
using bytes may cause some problems, but strings seem like a better
choice. As modules generated with current f2py error out, this
particular use is not common and we are free to choose.

Closes #4256.

Because Numpy 1.8.0 will no longer supports Python versions < 2.6 we
no longer need to check for that and can also remove the code that is
specific to those earlier versions.

To make this a bit safer, the toplevel setup.py file now contains a
check of the Python version number and raises an error when run by an
unsupported version.

In a few exceptional cases where symbols are shared between different
Python modules the use of `PyArray_API` in f2py (fortranobject.h)
conflicts with the regular use of the same symbol in the multiarray
module. Generally the symptom of this conflicting use is a segfault
when importing a f2py'ed module. This occurs because the module init
code somehow overwrites the first element of `PyArray_API` with the
location of `PyArray_API`, causing a crash when
`PyArray_GetNDArrayCVersion` is called.

Closes gh-2521.

compatibility functions in npy_3kcompat.h to replace the current calls.
This gets rid of a number of version checks and is easier to maintain.
Fix bug that was present in the ufunc _loop1d_list_free destructor in
the python3k case.