#33 Move to TreeCorr for correlation function tests

This is a PR to merge code that uses the TreeCorr package rather than corr2.  A lot of this is inside baseball for the workings of the CorrelationFunctionSysTest, but I will highlight in particular:
 - Most of the code is now gone from `corr2_utils.py` (now `treecorr_utils.py`).  You have no idea how excited I am about this.
 - The call signature for the CorrelationFunctionSysTests has changed: now it is
```sys_test(data, [data2, random, random2,] config=config_dict, **kwargs)```
instead of the old
```sys_test(config_dict, data, [data2, random, random2], **kwargs).```
The new form is more in line with the call signatures of the other SysTests, and I think it's clearer too.
 - Various places that "corr2" has been changed to "TreeCorr."
 - As long as I was changing imports, I went through and tidied up extraneous import calls in all files in the `stile` directory (all of which were, I'm sure, my fault in the first place).
 - Added a `fieldNames` dict to `stile_utils.py`, so we have an obvious in-Python place to look up what the fields should be called.  (Possibly we should do this for `object_type`s too?)
 - General PEP8ifying (spaces after commas, no trailing spaces on lines, etc)
 - Added a CHANGELOG.

Unfortunately, due to both rewriting a lot of the file & changing its name, the GitHub interface thinks `stile/treecorr_utils.py` and `stile/test_treecorr_utils.py` are entirely new files.  Hopefully it's not too terrible to read, though.
Yes, you can do that.  The problem is that for some of these statistics you have to do additional calculation, rather than just accessing attributes as-is (check the file `treecorr/k2correlation.py` and look at the `write` attribute, for example).  So our choices are to write out some (small) files to disk and read them, or write our own code that replicates the additional handling of the correlation functions (which is different for each type).  I thought the computation-time con was less important than the bug-avoidance pro, but am willing to listen to counterarguments!

The other possibility is to ask Mike to write a function that just returns these values, instead of writing them out...