Replace the IFP parameter enum with independent flags

[GuySten]

Replace the IFP parameter enum with independent flags

No behaviour change and no regolds, with one small bug fix noted below. This is
the cleanup half of #3728, split out so the delayed-activation work can be
reviewed separately.

Problem

IFP state is currently held in three places that have to agree with each other:

extern bool ifp_on;               //!< Use IFP for kinetics parameters?
extern IFPParameter ifp_parameter;

enum class IFPParameter { None, Both, BetaEffective, GenerationTime };

IFPParameter is a two-bit set written out as four named states. Because it is
an enum rather than two bits, turning one on requires a state transition:

case SCORE_IFP_TIME_NUM:
  if (settings::ifp_parameter == IFPParameter::None) {
    settings::ifp_parameter = IFPParameter::GenerationTime;
  } else if (settings::ifp_parameter == IFPParameter::BetaEffective) {
    settings::ifp_parameter = IFPParameter::Both;
  }
  break;

and reading one back requires a decoder, which is what
is_beta_effective_or_both() and is_generation_time_or_both() in ifp.cpp
exist to do. Between them they account for 24 call sites.

ifp_on is then a fourth piece of state that duplicates "is either bit set".

Changes

The enum and the two decoders are gone. The two bits are stored as two bits:

extern bool ifp_delayed_on;  //!< Store delayed group IFP data?
extern bool ifp_lifetime_on; //!< Store lifetime IFP data?

and ifp_on becomes derived rather than stored, so it cannot fall out of step
with them:

inline bool ifp_on()
{
  return ifp_delayed_on || ifp_lifetime_on;
}

Setting the flags in Tally::set_scores() is now a |= per score rather than a
state machine, and every is_*_or_both() call site reads the corresponding flag
directly.

All existing if (settings::ifp_on) guards are preserved as
if (settings::ifp_on()). Nothing is executed that was not executed before, so
there is no performance question to answer here.

Bug fix

free_memory_settings() did not reset ifp_on or ifp_parameter. Both are
derived from the tallies present in the model rather than read from XML, so a
second model loaded in the same process inherited IFP state from the first.

That is not only wasteful. The validation in Tally::set_scores() is guarded by
if (!settings::ifp_on), so with the flag already set the whole block was
skipped for the second model. A fixed source run with IFP scores would not have
raised "Iterated Fission Probability can only be used in an eigenvalue
calculation", and an out-of-range ifp_n_generation would not have been caught.
This affects anything running more than one model per process: depletion,
openmc.lib scripting, and the test suite.

Both flags are now cleared in free_memory_settings().

Testing

No results change, so the existing IFP regression and unit tests cover this
unchanged. The validation reordering preserves the previous "check once, on the
first IFP tally" behaviour: validation runs while ifp_on() is still false, and
the flags are set afterwards.

Notes

Follow-ups, kept out of this PR deliberately:

• The two data streams are structurally identical -- every function in ifp.cpp
  applies the same operation to a vector<int> stream and a vector<double>
  stream, and eigenvalue.cpp calls the MPI helpers once per stream. Folding
  the flag and both banks into one small type would remove most of that
  duplication. Still no behaviour change, so it can land on its own.
• Delayed activation of IFP tallies, which is the part of Add delay to activation of IFP tallies. #3728 that changes
  results and requires regolds.

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 18) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[JoffreyDorville]

Looking forward to these enhancements!

[paulromano]

@GuySten thanks for the simplification! This looks good to me. @JoffreyDorville did you want to look it over before we merge?

[JoffreyDorville]

@paulromano Yes, I'll have a quick look right now!

[JoffreyDorville]

Great work on the cleanup @GuySten ! I only have a single comment on renaming one variable, but other than that, it looks good.

[JoffreyDorville]

Thanks for the update. I just replaced wants_delayed as well to be consistent. Looks good to me!