Don't use deprecated numpy APIs

[jkseppan]

There are three main things about the deprecated APIs:

• some macros have been renamed, e.g. PyArray_UINT8 to NPY_UINT8
• you can't access PyArrayObject fields directly, instead you have to use accessor functions
• the old accessor macros are now functions so you can't call them with a PyObject* without typecasting

This changes the Travis configuration to require numpy==1.6 in one build, to ensure that we stay compatible with the version advertised in documentation. This also adds #defines to make reliance on the deprecated APIs a compilation error.

Fixes #2092.

[mdboom]

I like this. astropy is currently doing something very similar, though more controversially since astropy is still trying to support numpy >= 1.5.

I have no problems with this, as it seems to pass all tests.

[jkseppan]

One small thing: I noticed that this causes a massive number of warnings when compiling _macosx.m. Apparently the implicit cast on function call is legal Objective-C but produces a warning, whereas it's an error in C (or is it only in C++?). I could fix those errors before merging.

[jkseppan]

I tried that last commit by running IPython --pylab with the MacOSX backend and executing examples/pylab_examples/quadmesh_demo.py, examples/pylab_examples/tripcolor_demo.py and examples/api/histogram_path_demo.py. All demos seemed to work fine.

[mdboom]

Cc: @mdehoon

[jkseppan]

Since I fixed the problems found by @mdehoon and no one else has objected, is this ready to merge? I agree with @tacaswell's milestone of 1.5.x, there should be no need to backport to 1.4.x.

[tacaswell]

cc @mdboom I bet this conflicts with your massive cxx removal effort...

[mdboom]

@tacaswell: Yes, it probably does. It's going to be a pretty manual merge process, but at least I'll have this as a guide. It doesn't hurt to merge this, but it is likely to be short-lived.

[tacaswell]

Manually resolved the conflict and merged.