fluo_corr: normalize with the group's pre_edge ranges

[jhuang165]

fluo_corr() means to normalize with the options pre_edge() used for the group, but it reads them from group.pre_edge_details.call_args, which pre_edge() never sets (the arguments go to group.callargs.pre_edge through Make_CallArgs). So it always falls back to its own defaults: norm1=100, nnorm=1, pre2=-30, with E0 found again on each spectrum. Larix's Fluo Corr panel calls fluo_corr() without range keywords, so it goes through this path too.

That matters in two places:

• The correction uses the normalized input (mu * alpha / (alpha + 1 - norm)), so a different normalization gives a different mu_corr.
• norm_corr isn't normalized like norm, so the two can't be compared directly. On a short XANES scan norm1=100 can be past the last point. On a Fe K-edge fluorescence scan ending 98.5 eV above E0, with pre_edge() defaults, the corrected peak came out 1.171. Correcting with the group's own ranges gives 1.167, and that's also what you get by running pre_edge() on mu_corr with those ranges.

This PR takes pre1, pre2, norm1, norm2 and nnorm from group.pre_edge_details, plus group.e0. Those are the values pre_edge() actually used, including the ones it chose itself. Keywords passed to fluo_corr() still override them, and a group that was never normalized behaves as before.

I first tried group.callargs.pre_edge. That only records what the caller passed, mostly None, so preedge() re-derived E0 and the ranges from the corrected spectrum, and norm_corr still differed from norm's normalization (1.172 in the example above).

tests/test_xafs_fluo.py checks that fluo_corr() on a normalized group matches passing the group's ranges explicitly, after default and after custom pre_edge() options, using examples/xafsdata/fe2o3_rt1.xmu. Both cases fail on master and pass with the change.

I found this while fixing larch_fluo_corr in xraylarch-mcp (Joint-Photon-Sciences-Institute/xraylarch-mcp#5), which now passes the ranges explicitly as a workaround.

[newville]

@jhuang165 Thanks -- you are absolutely right that fluo_corr should read from pre_edge_details. Merging.

We should probably also force the call to pre_edge() to set e0=None so that e0 is recalculated—a large correction can affect that.