Improve EKOs product

[alecandido]

At the moment, the product is implemented in ekobox.utils, but it is rather naive:

1. it is not updating metadata, that remain those of the initial object (since it's cloned)
2. it is not doing a proper job when paths collide: a -> b -> c is not used when a -> c already existed in the LHS

In order to address point 1. a stable output is needed (as requested in #77 and sketched in #105).

The second point is rather subtle, since one might think that the two are the same, and it might want to use the already existing one not to accumulate more numerical error.
This is true only if the theory is the exact same, or somehow compatible. Otherwise, playing with the thresholds for nf, the two objects might be really distinct.

Since solving the problem of point 2. in general might be extremely complicated, we can keep doing what we're doing now, but implementing strong consistency checks on the theories related to the operators.
We can still allow for some differences (e.g. in evolution method), but we need to nullify all the entries in the metadata that have no single consistent value (such that you have to read the components' metadata).

• add proper checks
• compute proper metadata for the product (including null ones)
• log operations into history.yaml and runcards to {n+1}.theory.yaml and {n+1}.operator.yaml
• add product subcommand to the CLI

[alecandido]

The most recent proposal is to avoid complex operations on EKOs, and thus completely drop this feature.

@NNPDF/theory