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

Yes, those docs are correct.  You need the photometry functions because `F` and `\Delta F` are calculated (summed) over the aperture or segment of interest.  (I not sure what you mean).

The `gain` parameter isn't necessary.  One could remove the parameter and then require `error` to be the *total* error for the photometry routines.  The total error image is simply `np.sqrt(error_b**2 + (data / gain))`, where `error_b` is the "background"-only error, e.g. see the new Notes section here:
http://www.stsci.edu/~lbradley/photutils/segmentation/api/photutils.SegmentProperties.html#photutils.SegmentProperties

Yes, we could have a utility function that calculates "total error" from the data, the background error, and the gain.
However, the detection routines require an `error` input that consists of background-only error.  So that means one would need to carry around two "error" arrays, one background-only and one total error.  Also, the error input into both `detect_sources` and `segment_properties` is called `error`, but the `error` input arrays cannot not be the same if `gain` is removed from the photometry routines.  I think that will lead to confusion even if the difference is documented.  We could change the `detect_sources` input from `error` to `background_error` or `background_rms` (more commonly used).  But then it's going to be more difficult to work with an `NDData` container (if that happens).

On balance, I think I still favor the current API with separate `error` and `gain` parameters (`gain` is usually just a scalar) versus carrying around separate `background_rms` and `total_error` arrays (which could be large) and functions with different error parameter names.  Any thoughts? @astrofrog, @eteq