Segmentation photometry and morphological properties

This large PR adds two new functions to perform photometry and calculate morphological properties of sources defined by segmentation images (e.g, from SExtractor or made with `detect_sources`).  When the segmentation image is defined using a thresholded flux level (e.g., `detect_sources`), `segment_photometry` is equivalent to performing isophotal photometry in SExtractor.

I still need to write tests for these new functions, but this is ready for review.  I've done some comparisons to SExtractor, and with the same input segmentation image and background, the photometry and morphology results are identical.

Docs for updated `detect_sources`:
* http://www.stsci.edu/~lbradley/photutils/segmentation/api/photutils.detect_sources.html#photutils.detect_sources

Docs for new `segment_photometry` and `segment_properties` functions:
* http://www.stsci.edu/~lbradley/photutils/segmentation/api/photutils.segment_photometry.html#photutils.segment_photometry

* http://www.stsci.edu/~lbradley/photutils/segmentation/api/photutils.segment_properties.html#photutils.segment_properties

New `SegmentProperties` class:
* http://www.stsci.edu/~lbradley/photutils/segmentation/api/photutils.SegmentProperties.html#photutils.SegmentProperties

I could make a separate function to interpolate masked pixels that the user calls before calling the detection/photometry routines.  Once masked pixels are interpolated, they become valid pixels so the `mask` is not needed in the detection/photometry routines.  For example, after applying `_prepare_data`/`_apply_mask` on the inputs, `SegmentProperties` subsequently ignores the `mask` if `mask_method = interpolate`.

However, "excluded" masked pixels are different.  They would still need to be handled by passing a `mask` to the detection/photometry functions.  `_apply_mask` sets excluded masked pixels to zero, which is OK when summing over pixels, but the real `mask` is needed for other properties (internally I'm using a `masked_array`).

So the alternate API would be this.  We could make the input ``mask`` on the routines be *only* for excluded pixels and remove the ``mask_method`` parameter.  If instead you want to interpolate over masked pixels, then e.g., you'd need to run `interpolate_masked_data` (or run your own custom interpolation) and then pass the interpolated `data`, `error`, and `background` arrays to the routines (without a `mask`).  That seems fine to me.  Thoughts?  @astrofrog, @eteq?