#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.
Hmm, that's an interesting point.  I think the list-comprehension versions are implicitly reusing the lookup (or that's my guess) and that's why they go faster; I've moved all of the columns that involve multiple lookups to a separate function anyway so I don't think this will add any speed at this point.  If things still seem too slow to others it might be worth looking into though.  

I guess the other question is, are there savings to getting all the keys to the schema at once?  We really look up a lot of them (all the flags in addition to the shape values, etc) so if that's faster it might be worth it.