#529 - imposing isotropy or at least N-fold symmetry on correlated noise

This pull request is for some small additional functionality in the handling of correlated noise, which is parallel to the whitening functionality that was already in place but involves imposing N-fold symmetry on the noise (without making it white).  Here N is some even integer >=4, with the default choice being 4, likely the lowest order of symmetry necessary to avoid weird shear systematics due to anisotropic correlated noise.

In general, the amount of noise that has to be added is substantially less than what has to be added to make correlated noise in COSMOS images fully white.  So that would be the main motivation for doing this instead of whitening.

Based on some discussion on #529, the ```applyWhiteningTo()``` method has been changed to ```whitenImage()```, parallel to the new ```symmetrizeImage()``` (though ```applyWhiteningTo()``` still works for now).   Mike put the new symmetrizing option into config, and moved the existing whitening option in config from being an attribute of the real galaxies to being specified at the same time as the noise in the final image.  (Mike, should we update the config wiki once this is merged?  Or did we decide the wiki was going to correspond to the latest tagged version?)

@emhuff , this should be helpful for you...
>This involves drawing the correlation function in a larger image and doing the DFT. The alternative is drawing the correlation function into an image corresponding to image.array.shape, doing the DFT to get the PS, and then padding the PS image.

>Is there some reason to prefer the latter? (which seems to be what you were suggesting)

There are a few reasons I suppose:
* It will help reduce the number of `rootps` arrays overall that need to be calculated and cached
* The code will be more parallel in structure to the whitening and basic noise generation code
* Say you are making a postage stamp of size NxN that is sensibly chosen to be fast for FFTs, that (N+1)x(N+1) is usually not fast for FFTs, often it may be prime
* Your generated noise field will have subtly different edge behaviour than the other noise fields, being not strictly periodic, which may make writing tests a bit trickier (this periodicity is not exactly a desirable feature in the other noise fields, being unrealistic, but is not disastrous... and it conveniently makes much of the testing more exact if this can be assumed when taking DFTs to check output correlation properties)

The "padding" (I'm not sure I like the name padding because it suggests zero-padding, when I just want to make there be symmetric copies of the ux/uy = +/- .5 array elements) would only need to be in place for a short time, essentially only during the rotation loop stuff.  HAving done this loop, but before line 834 (i.e. `final_arr = utilities.roll2d(final_arr, (-final_arr.shape[0] / 2, -final_arr.shape[1] / 2))`), you would take a subset from `final_arr`, of the original size of the `ps` and excising the padded region, re-roll, then return an even sized `final_arr`.