#7 HSC/LSST interface code

This pull request contains code that interfaces Stile with the HSC/LSST pipeline.

Most of the action in this PR happens in a new module for Stile called "lsst".  It is found in stile/lsst.  (This is actually kind of misnamed at the moment--it relies on HSC functionality that isn't in the LSST side yet.)  There are two files of interest in that directory: 
- `sys_test_adapters.py`, which makes objects that wrap the Stile tests in a way that makes them useful for LSST;
- `base_tasks.py`, which contains LSST-pipeline-like Task objects to pull data from the butler, coerce it into a format that Stile likes, and then call the wrapper objects from `sys_test_adapters.py` to run the tests.  We've inherited from the LSST Task classes, which let us use the pipeline parser functionality to describe which data we're interested in: this is the 'visit ID' stuff from the pipeline documentation.

You actually run this code via some scripts in the (new) `bin/` directory.  The available scripts are:
 - `StileCCD.py` : run CCD-level tests.  This version assumes you're running on a CCD that has been used in a coadd and can use the coadd-level photometric calibration, etc.  If there's no coadd associated with the CCD--if you only ran the single-frame processing--then you run:
 - `StileCCDNoTract.py`
 - `StileField.py`, `StileFieldNoTract.py`: run field-level (single-exposure) tests.

Four science choices that I wanted to highlight as needing particular input or ideas or verification from others:
 - We have a "bright star selection" code block to pick bright stars.  Right now it selects the top 10% of bright stars, but--due to some quirks in the way I coded this up--that will always run on a per-CCD level rather than on a per-field level even if we ask for fields.  So it's probably better to have a hard cutoff.  What should that cutoff be?
 - One possible test is to run a galaxy-galaxy shear measurement around galaxies--not to do real science, and not weighted by redshift, just average shears.  For that, we need a galaxy lens sample.  Is there an obvious subset of galaxies we should be using for this?
 - At the moment, when we need galaxy weights for correlation function-type tests, we just return 1 for all objects.  That's probably a bad choice.  Is there something in the catalog we should be using, or should we be pulling weights based on the shape measurement error, or something else?
 - The flags that we use to exclude data (the flags in the list in 'removeFlaggedObjects') were chosen to be conservative right now--we're only looking at things we're fairly sure are well-measured.  We will probably want to relax this in future (and make it configurable without editing the source code too).  
 
This PR also includes some more systematics tests (shear around bright stars, star-star shape correlation function, galaxy-galaxy lensing type correlation function); they're all extensions of the existing CorrelationFunctionSysTest framework, so not much code there.  I also added a rather unwieldy but flexible-to-the-user plotting function for the correlation function tests.
 
Still to be done:  
-  As Hironao noted in issue #22, we don't let the user select tests right now--the list is hard-coded.  
-  Tract and patch (coadd-processing) level tests.  Shouldn't be too hard to code up, but Hironao has new code that is waiting on this branch.  
- We don't generate randoms.  We will need to eventually, but in the meantime we can't run any tests that use two-point correlation functions, because corr2 requires randoms for those.  
-  Two of the systematics tests included in `sys_test_adapters.py` are commented out of the default tests-to-do lists in `base_tasks.py`.  That's because of issue #23, so they should be included once that's finished.
- At the moment we don't have any unit tests.  I'm not sure exactly how we do that without assuming some available data (or, really, even once we have some data to run it on)--perhaps @TallJimbo or @HironaoMiyatake could advise and I could add that to this branch?
 
I want to especially thank @TallJimbo and @HironaoMiyatake who put a lot of work and time into this PR as well, which may not be represented in the git history for these files.
Well, the `.test_name` and the `.cols_list` are pretty straightforward.  The `.mask_list` is more complicated since it requires different code for the CCD and the visit versions (and relies on the data and the config object, though we could just pass those as arguments to the constructor), and that's really what most of the code is where we're initializing `sys_test_data`.  In fact I don't think it would really save us any lines of code--we'd be moving the mask generation wholesale to the constructor with an `if` to figure out which one to do, and other than that it's 2 lines of code--right now we have that repeated (4 lines) but otherwise we'd have the 2 lines + 2 constructor lines.

It may or may not be a bad idea as we add more functions to this class, and I'll keep it in mind, but I don't think it really saves us anything to do it here.  Do you think the code would be easier to read if we moved this to an initialization block, even if it doesn't save us anything in terms of code deduplication?