#618 - interpolated chromatic objects

Hi all -

Sorry for the obnoxious holiday-season pull request.  I realize this might not get attention for a while.

This pull request is for the new ```InterpolatedChromaticObject``` class and its subclass, ```ChromaticOpticalPSF```.  The former is a way of expediting calculations related to chromatic objects that can be described as GSObjects that have wavelength-dependent keywords or transformations applied to them.  The latter is a specific example for describing the wavelength-dependence of optical PSFs.

This class has a number of keywords that control its speed and accuracy.  It is possible to easily turn off the interpolation and make it do the exact brute force calculation.  For some simple examples that I tried, the startup cost of instantiating one of these ```ChromaticOpticalPSF```s is of order 1 second, and the time to actually draw is 1/10 the time to draw when doing the full calculation.  Often for a single object, the interpolated calculation is not worthwhile due to the overhead, but as soon as this is used for mass production, the interpolated calculation pays off very quickly.  Note that as long as the object was instantiated with sufficient wavelength coverage, it can be reused when drawing through different bandpasses or when convolved with objects that have different SEDs, so the overhead doesn't have to be incurred multiple times.

A few comments and questions:

* When writing the ```InterpolatedChromaticObject``` class, I clearly had ```ChromaticOpticalPSF``` in mind as the main application.  I am open to comments on parts of ```InterpolatedChromaticObject``` that should be generalized for other applications.

* @jmeyers314 , I was wondering if I should use this class to simplify the atmospheric PSF class that you wrote?

* I gave some thought to the issue of flux normalizations since it seems that sometimes ```InterpolatedChromaticObjects``` will be used for PSFs (e.g., ```ChromaticOpticalPSF```) convolving a chromatic galaxy, whereas other times it'll be used as an object with some SED leading to a flux calculation in a given band (if someone makes a galaxy that has wavelength-dependent properties using this class, or if they want to draw a star image corresponding to a ```ChromaticOpticalPSF``` with some SED and SNR).  Right now, my solution is that the ```InterpolatedChromaticObject``` carries around an ```SED``` attribute, which by default is flat, i.e., ```lambda w : 1.0```.  This is what we want if it's to be used as a PSF convolving a chromatic galaxy.  However, it's possible to assign an SED at the time of initialization or make a new instance with a new SED using the ```withSED``` method; in this case, the object has a well-defined flux through each band, as defined by the SED.   For example, if we want to draw an image of what the effective PSF is for a galaxy with a given SED, then we have to assign that SED to the ```ChromaticOpticalPSF``` before drawing.

Note that changing the SED does not incur the overhead of making a completely new object, since the new object just copies over all the data (stored images, etc.).  The documentation of this behavior might not quite be sufficient.  I first wanted to get some feedback on whether this way of dealing with SEDs makes sense, and if people agree then I will add some more information or perhaps examples to the docstring.