#563 - Make the generation of correlated noise more efficient using Hermitian symmetry

Hi all,

This pull request was to make the generation of noise by the `BaseCorrelatedNoise` and derived classes more efficient, using the fact that we only desire real valued noise fields in the output.  It took me longer than I hoped to get right! (There is a script, part of this PR, in `devel/external/test_cf/` that I used as a sandbox to get this right.)

The main change then is this improvement, which happens almost exclusively within the `_generate_noise_from_rootps()` function in `galsim/correlatednoise.py`.  Since the cached variable `rootps` is now only ~half the size, this improvement also helps memory use and setup costs too.

Another, more minor change is that I no longer multiply the `rootps` values by the product of the original array shape when storing them internally within the `BaseCorrelatedNoise`.  This is necessary to do somewhere because of the asymmetry in the the `numpy.fft` convention for the DFT, and the fact that the power spectrum (PS) has the units of the square of a DFT of a noise field.  I opted to move this accounting into the `_generate_noise_from_rootps` function, simplifying `_get_update_rootps()` and `_get_update_rootps_whitening()` slightly, while on the downsise adding an additional instruction (do divide by an array dimension product) to the `CorrelatedNoise.__init__()` method.  It was a marginal call, but from working with the code this way of doing things seemed more natural, and less hidden.

I don't have a great deal to add to the discussion on #563 .  The current state of the noise realization generation code is described in the following comment: https://github.com/GalSim-developers/GalSim/issues/563#issuecomment-48053798 .
>How does that follow?

Because in the commented line the only think I am doing is calculating |z|^2 for (an array of) complex z, barring the assignment operation.  Assignment doesn't have any possible alternatives among which the use of `abs()` could be described as having an edge, so if I were reading this I think I would be forced to conclude that it must be the calculation of |z|^2 that is being referred to.

> I wasn't sure if the comment was meant to justify the change from one option to another (i.e., you tried those two options), 

I wrote the comment for the reader of the code, not for the reader of the diff: I don't think the latter would be a good idea.  It was five minutes' work to time a few competing options, but I didn't feel it was worthwhile documenting each tried, because in this case this operation contributes only minimally to the overall costs of calculating the PS - the DFT in the line above totally dominates.  So I said simply that `abs()` appears to have the slight speed edge, thinking that in the absence of a specific list of competitors the statement would be understood as general, which in this case is the meaning intended.

>However, it's really not a big deal and if (as I gather from your comment) you think it's obvious to anyone but me, then don't worry about it at all.

You gather wrongly: for me this is the only thing that can conceivably be being referred to, via the argument I describe above, and what I said was that this is the assumption I was working under when I made the comment.  That assumption was clearly wrong. I wasn't singling out anybody in particular as examples of people who don't follow my own brand of twisted logic, although I do think that I can defend it.  This discussion has already taken more time than will likely ever be saved by this optimization.