Refactor harmonic cache

[giacomomagni]

Since we have introduced a lot of new elements we will need to restructure the harmonic cache.

Reimplementation of #202

• Add the cache, tests and relative cleaning
• Rewrite all the anomalous dimension modules and relative tests
• Rewrite all the matching conditions modules and relative tests
• Benchmark and check for any numba error

[felixhekhorn]

Unfortunately, our hope of a small speed up doesn't seem to be true (LHA bot ran here in 33m and on master on 31m) - nevertheless, I'm still convinced this is a good idea ... (also the impact on eko is minimal which is good)

(in a future PR we may want to harmonize the arguments of the various functions n,cache,nf vs. n,nf,cache - but that is really minor ...)

[alecandido]

(LHA bot ran here in 33m and on master on 31m)

The exact timing should not be measured on GitHub Actions machines: they are not uniform, and most likely virtual, so you never know the exact performances on comparable hardware.

However, the message is that the order of magnitude is unchanged.

[giacomomagni]

Unfortunately, our hope of a small speed up doesn't seem to be true (LHA bot ran here in 33m and on master on 31m) - nevertheless, I'm still convinced this is a good idea ... (also the impact on eko is minimal which is good)

Are you sure this do not depends also on other factors? I checked that some older benchmark took longer other were quicker... Most likely we haven't gained much apart in code cleaning and #143

(in a future PR we may want to harmonize the arguments of the various functions n,cache,nf vs. n,nf,cache - but that is really minor ...)

True