Numerator Evaluation with counterterms

[lcnbr]

This PR brings a number of upgrades to gammaloop.

• Numerator evaluation integrated with cff and ltd
• Threshold counterterms that actually take into account numerator
• A new input graph format based on DOT.

These changes also forced some reformatting of the codebase, namely:

• The graph struct now is split into two parts:
  • BareGraph which includes all constant data and encode the graph structure. This should not be mutated after deserialization. If one needs to add information dependent on the graph structure it should happen when deserializing.
  • DerivedData which is associated data that gets populated later on, namely CFF and numerator
• The momentum signature is now built into a struct, separating the external signature from internal loop momentum signature. Applying a signature can be done on any iterator with elements that can be summed and negated.
• To enable serialization of symbolica evaluators, custom Serializable evaluators from spenso are used
  • SerializableAtom also can be used for expression serialization however this serializes the state each time so shouldn't be the default
• All of symbolica's evaluation API was mirrored to all symbolic variants of spenso's tensors, including special evaluator structs that output sets of tensors.

Details

Numerator

This PR contains the ability to evaluate the numerator associated to a graph through application of Feynman rules encoded in a UFO format. For amplitudes the open lorentz and spinor indices are saturated with polarizations. The numerical value of these (lorentz or bispinor) vectors is computed from the external momenta using the conventions of HELAS. This also means that we had to use a transposed version of the weyl gamma matrices for things to match. The polarizations naturally depend on user defined helicities, that are provided in the same way as for external momenta.

Alternatively, a global numerator can be provided:
ExportSettings.numerator_settings.global_numerator: Option<String>
It can be any string that can be parsed by symbolica and use spenso's tensor format.

Additionally, a global prefactor :Option<GlobalPrefactor> (also in NumeratorSettings) can be provided to saturate all open indices, namely the color indices. This prefactor is split into two: the spin/lorentz prefactor and the color prefactor. Both can be sums of tensors with matching indices.

The obtained expression (global x prefactor or local x prefactor) is stored in the struct Numerator<AppliedFeynmanRules> or Numerator<Global>. Thus the numerator struct is compile time stateful, out of order operations literally cannot compile.

This object can then be simplified in color algebra using fierz identities turning into Numerator<ColorSimplified>. Then it can either be turned into dot products using gamma algebra Numerator<GammaSimplified>, or concretized using spenso: Numerator<Network>. This network version supports showing the network graph using spenso's rich graph output for tensor networks.

From there both versions of the numerator are turned into evaluators by calling .contract() turning them into Numerator<Contracted>. This will be a scalar in the gamma simplified case, but could be a tensor with open indices in the spenso concretized version.

This is then turned into an Numerator<Evaluators> using .generate_evaluators(..). This turns the scalar or tensor expression into an object that can be evaluated (implements the evaluate trait) for a single emr set, or for all the cff orientations at once. The backend evaluators are either linearized evaluators or compiled ones as set in the ExportSettings.numerator_settings.eval_settings:

#[serde(tag = "type")]
pub enum NumeratorEvaluatorOptions {
    #[serde(rename = "Single")]
    Single(EvaluatorOptions),
    #[serde(rename = "Joint")]
    Joint(EvaluatorOptions),
    #[serde(rename = "Iterative")]
    Iterative(IterativeOptions),
}

pub struct IterativeOptions {
    pub eval_options: EvaluatorOptions,
    pub iterations: usize,
    pub n_cores: usize,
    pub verbose: bool,
}

pub struct EvaluatorOptions {
    pub cpe_rounds: Option<usize>,
    pub compile_options: NumeratorCompileOptions,
}

#[serde(tag = "subtype")]
pub enum NumeratorCompileOptions {
    #[serde(rename = "Compiled")]
    Compiled,
    #[serde(rename = "NotCompiled")]
    NotCompiled,
}

A single evaluator will not optimize all orientations at all, and thus when asking for all cff orientations, will get called once per orientation. A joint evaluator is optimized as a whole, across all orientations. The iterative evaluator is for when joint optimizing is unfeasable. This reuses the horner form of the initial orientation.