Fix computeBunchMoments bugs, BunchTwissAnalysis refactor, bump to C++17

[woodtp]

Fixes #121.

Based on #122.

The moment calculation bugs are corrected, and an additional normalize flag is added to computeBunchMoments to prevent normalization of x-y moments by powers of either $\sqrt{\beta_{x,y}}$ or $\sqrt{\beta_{x,y}\varepsilon_{x,y}}$ unless explicitly requested.

The class has been reworked to expedite calculation of moments up to 2nd order, which is the most common use case. Previously, calling computeBunchMoments would scale as $O(N^2)$ due to a double loop over the
Bunch. Now, the double loop is triggered only if moment orders $\geq3$ are requested. Maybe there's a clever way to get around doing the loop twice, but my impression is that these terms are not needed very often anyway.

I've also unified computeBunchMoments and analyzeBunch and marked the analyzeBunch method with [[deprecated]]. The choice is sort-of arbitrary, but I think we should favor computeBunchMoments as the entry point, because the name is more descriptive. Previously, both methods calculated moments; the difference was that analyzeBunch was calculating up to 2nd order moments, while computeBunchMoments itself called analyzeBunch before calculating x-y moments up to the requested order. analyzeBunch will still work until removed, but will now emit a warning message (only at first invocation) that computeBunchMoments should be used instead before forwarding arguments to computeBunchMoments.

Bumping the c++ standard allows us to more easily compose specialized implementations of the moments calculation based on whether the dispersion correction is enabled or the macrosize bunch attribute is
defined. When these two conditions are false, the compiler should be able to optimize-out the extra instructions within the Bunch loop(s) that these scenarios require.

Questions

1. Should the normalization and/or dispersion correction apply universally? If dispersion or normalization are enabled, they are only applied to the x-y moments returned by getBunchMoment(i, j) and not getCorrelation(i, j).
2. Should BunchTwissAnalysis be able to compute higher order moments between all combinations of $x, x', y, y', z, dE$ as opposed to just $\langle x^i y^j \rangle$?

[woodtp]

Note that these lines are the only true changes to wrap_bunch_twiss_analysis.cc. Everything else is just formatting via clang-format.

[woodtp]

CI checks for every build except apple-silicon are failing. Based on the errors, I think it's because g++ has a different opinion about the included header paths compared to clang; I'll need to poke around a bit to figure out what's going on.

Converting to draft.

[shishlo]

Quote: “I've also unified computeBunchMoments and analyzeBunch and marked the analyzeBunch method with [[deprecated]]. The choice is sort-of arbitrary, but I think we should favor computeBunchMoments as the entry point, because the name is more descriptive.”

I asked Google:
In statistics, is there difference between moments of values and correlations?

Answer:
Yes, there is a clear difference, but they are also connected because a Pearson correlation coefficient is actually a specific type of standardized product moment.

So, I am not sure that computeBunchMoments is the same as analyzeBunch. I seems to me that analyzeBunch is more appropriate name.

[austin-hoover]

@shishlo The function analyzeBunch calculates the first and second moments; it fills avg_arr which is the mean $\mu = \langle {z} \rangle$ and corr_arr which is the moment matrix $\langle {z} {z}^T \rangle$. The function getCorrelation(i, j) returns the i, j element of the covariance matrix $\Sigma = \langle ({z} - \mu) ({z} - \mu)^T \rangle$, not the correlation matrix. So getCorrelation should be called getCovariance.

[austin-hoover]

And corr_arr should be called moment_arr or something else.