A NaN interpolation point was interpreted as out of bounds on the left
side, hence the value of the left parameter in the function call was
returned.

>>> np.interp(np.nan, [-10, 10], [-2, 2])
-2.0

NaN is a better choice.

Closes #605.

`bincount` checks its input array to make sure there are no negative entries,
and to determine the size of the output array. This is done by calling two
different functions, each having to loop over the whole array. This PR
adds a new function, `minmax`, that computes the minimum and maximum of the
array in a single pass over it. This leads to speed-ups peaking at 1.5x,
with typical values for large arrays around 1.15x - 1.25x.

A full benchmark summary of the new implementation, including a supposedly
more efficient algorithm that turned out to run slower, can be found [here](https://gist.github.com/jaimefrio/8743836).

       minimize indexing.

MAINT: rewrote `check_array_monotonic` to use array indices, not pointers.
TST: tests for proper handling of bins with all items almost equal now check
     the return value for correctness, not just that an error is not raised.

The check for monotonic bin arrays of digitize doesn't properly handle
inputs with repeated entries at the beginning of the array:

```
>>> np.__version__
'1.8.0'
>>> np.digitize([1], [0, 0 , 2])
array([2], dtype=int64)
>>> np.digitize([1], [2, 2, 0])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: The bins must be monotonically increasing or decreasing
```

Modified `check_array_monotonic` in `_compiled_base.c` to skip over repeating
entries before deciding to check for increasing or decreasing monotonicity
and added relevant tests to `test_function_base.py`.

Deallocation should just do nothing if provided a NULL pointer nditer
deletion broke this convention.
Removed many redundant NULL checks for various deallocation functions
used in numpy, they all end up in standard C free or PyMem_Free which
are both NULL safe.

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.