Refactor implementation of falloff reactions

[ischoegl]

Is your feature request related to a problem? Please describe

The implementation of falloff reactions separates falloff and chemically-activated reactions (a relatively minor binary distinction) while introducing a FalloffFactory. This solution (while historical) appears to be more complex than necessary.

Describe the desired solution

Removal of FalloffFactory simplifies the reaction structure by explicitly specifying three falloff variants, i.e. falloff-Lindemann, falloff-Troe, and falloff-SRI. Further, it is sufficient to define chemically-activated as a boolean field (that defaults to false).

- equation: ch3co (+ M) <=> ch3 + co (+ M)
  type: falloff-Lindemann
  low-P-rate-constant: {A: 1200000000000000.0, b: 0.0, Ea: 12517.93}
  high-P-rate-constant: {A: 3000000000000.0, b: 0.0, Ea: 16719.89}

- equation: ch3 + oh (+M) <=> ch2o + h2 (+M)
  type: falloff-Troe
  low-P-rate-constant: {A: 282320.078, b: 1.46878, Ea: -3270.56495}
  high-P-rate-constant: {A: 5.88e-14, b: 6.721, Ea: -3022.227}
  Troe: {A: 1.671, T3: 434.782, T1: 2934.21, T2: 3919.0}
  chemically-activated: true

- equation: R1A + R1B (+M) <=> P1 + H (+M)  # Reaction 1
  type: falloff-SRI
  low-P-rate-constant: {A: 4e+25, b: -3.0, Ea: 0.0}
  high-P-rate-constant: {A: 1e+18, b: -2.0, Ea: 1000.0}
  SRI: {A: 0.54, B: 201.0, C: 1024.0}
  efficiencies: {R3: 2.0, P2A: 5.0}

Describe alternatives you have considered

The current YAML implementation differentiates the falloff types based on the existence of SRI or Troe fields. A refactoring of the C++ code does not depend on a change of the YAML syntax.

Additional context

Change of YAML and refactoring of C++ code is independent. PR #745 creates a basis for easy adoption of the alternative reaction definition. As YAML is not yet officially released, the syntax modification can be easily incorporated into 2.5.

[ischoegl]

Closing this as I don't think it is necessary as described (flattening the structure has no significant benefits, as it's easy to interpret the current implementation as type and subtype).

I still believe that there isn't a good reason to differentiate between falloff and chemically-activated, as the difference is marginal and does not warrant maintaining two separate classes. I will open another issue on this eventually.