Adding do_photometry as aperture member

This idea of making a do_photometry method in the apertures came up during our telecon a few weeks ago. I've eliminated the ``encloses()`` method in favour of the ``do_photometry``.

 Here are some of the trivial pros and cons, as I see it:

Pro: 
- removes the creation of temporary arrays (subdata), thus a little bit faster when we have multiple positions. In numbers: https://github.com/astropy/photutils/wiki/Aperture-photometry-benchmarks
- the apertures deal only with pixelcoordinates, and the higher level ``aperture_photometry()`` function does the preprocessing of hdus/wcs/skycoords/masks/etc, but doesn't hold any numerical functionality.

Con:
- the code becomes more fluffy and contains some repetition.
- the apertures are not pure geometry objects any more (but since they had the positions, the ``enclose()`` method have already lost its generality).

The main question is whether we go to this direction, or keep the original API stucture?

I've only fixed a few tests and temporary removed the rest, but didn't touch the docs, so I assume all travis build will fail with doctest problems. Also, the current version doesn't support error and mask arrays, I'll put back their support once we decide to follow this API structure. 

cc: @cdeil, @astrofrog, @eteq, @larrybradley, @adonath
Thanks, indeed. 
I think it's nicer to deal properly with nan data values, but I'm not sure that we actually need this here as ``np.sum`` will fail anyway when doing the photometry on the nan pixels. And changing all of those  to ``np.nansum`` means slowing down the whole API significantly.