Created new classes to handle DSS images and downloading of DSS images

1. Moved KSUtils::getDSSURL() to KSDssDownloader::getDSSURL() with
   expanded, but backward-compatible options.

2. Created a new class KSDssImage to load and hold a DSS Image as a
   QImage along with a metadata structure. The metadata struct is
   designed to supplement information about the DSS image (eg: size in
   arcminutes, center RA/Dec, photometric band, generation of DSS
   etc.)

3. Created a new class KSDssDownloader which completely takes care of
   downloading DSS images given a SkyPoint and a destination file. It:

   - Formats the URL
   - Sets up a download job
   - Tries alternate versions if the download failed
   - Writes the file along with metadata as a compressed PNG image

4. Employed this new machinery in ObservingList

5. Regression: partial removal of (anyway broken) SDSS support

Motivation:

+ DSS images are heavily used by visual astronomers to compare what
  they see in the eyepiece with imagery. These are far superior to
  "photoshopped" / HDR-ed astrophotographs since the brightness is
  roughly a real measure of brightness.

+ Visual astronomers prefer blue images to red images since they
  closer approximate what may be seen with the eye. However,
  sometimes, blue images are not available, so it is inevitable to
  fall back to red. In these times, it is important to know what plate
  is being looked at (blue or red)

+ We intend to eventually be able to overlay DSS images on the sky
  map. A system for caching and rendering compressed (PNG as opposed
  to FITS) DSS images may be important, and this requires proper
  metadata.

Solutions:

+ KSDssImage ensures that image and metadata are kept together. The
  width and height are important meta data for any DSS image. While
  these could be figured using a pixels/arcminute ratio, this ratio is
  not the same across various generations of the DSS.

+ KSDssDownloader goes through a sequence of attempts at downloading
  DSS images in an order that is set by us, rather then set by the
  MAST website (which would be the case if we did not specify which
  version we want). The MAST website prefers POSS II Red > POSS II
  Blue > POSS I Red etc. whereas we would want to prefer POSS II Blue
  > POSS II Red > ...; More powerfully, this sequence may be a
  configurable option later.

  The other advantage of doing this sequence, instead of letting the
  DSS search find a version for us, is that of knowing what we've
  got. The gif from MAST website has no metadata in it (although GIF
  does support metadata). This means we don't know which version of
  the survey we got.

+ Test cases: Palomar 6 is an interesting test case because POSS II
  blue plate is unavailable. The script figures out that the blue
  plate failed, and fetches the red plate instead. The advantage of
  KSDssDownloader is that we now know that we are holding a red plate
  -- it's in the PNG metadata.

Future:

+ Need to expand to SDSS. Then, allow for proper detection of whether
  the coordinates fell in SDSS footprint or not. Then, use the same
  falling-through to fall-back to DSS after SDSS.

+ Ability to compose a closest approximation to visual view from R/B
  plates

+ DSSimage SkyComponent that holds multiple DSS Images along with
  their respective coordinates.

CCMAIL: kstars-devel@kde.org