Change representation of the luminosity function

[cschwan]

The current representation of the luminosity function, which is essentially the type LumiEntry, makes it very hard to convolute a grid for a single tuple of partons only, see also #150. We should:

• add a new method Grid::lumis that returns simply a Vec/slice of tuples (a, b, factor, index) with a and b being the two partons and index being the same each tuple from the same LumiEntry the Grid was constructed with. The method Grid::lumi should be removed
• change the Grid::convolute function to accept a slice of boolean that correspond now to the slice returned by Grid::lumis instead of the shorter vector of LumiEntry objects the Grid was constructed with. This will allow more fine-grained control over convolutions.

[alecandido]

This would be nice, such that we'll be able to do:

grid.convolute(
    ..., 
    grid.lumis().iter().map(|(a, b, _, _)| myfilter(a, b)).collect(), 
    ...
)

[cschwan]

Exactly, that's the idea, it should become much simpler.

[cschwan]

I'm no longer sure this is a good idea, and I'm closing this in favour of #149, which should allow implementing an operation that 'splits' each channel of a luminosity function that the new channels contain FK table-like entries, in the sense that we have a single tuple (a, b, f) with a and b initial-state partons and f and arbitrary factor. This allows `pineappl channels to show the size of each flavour-combination.

[alecandido]

an operation that 'splits' each channel of a luminosity function that the new channels contain FK table-like entries

At result level or at grid level? Because I would not recommend the second, I definitely want to avoid copying subgrids.

Now I really appreciate that the concept of LumiEntry is not the same as a parton tuple, because actual "channels" (mapping to diagrams and expressions) are much less than tuples. In principle, it would be nice to apply also in DIS, but quark masses treatment (including intrinsic flavors) complicate enough the situation - you might end up with a similar number of channels (and DIS grids are small anyhow, making it less appealing).

[cschwan]

See https://github.com/NNPDF/pineappl/issues/149#issuecomment-1401941206. That copies subgrids, which is unavoidable for duplication of them.