use beta gamma CKM scheme as default

[peterstangl]

This PR changes the default CKM scheme to the beta gamma scheme, which, compared to the Tree scheme, uses the UT angle $\beta$ instead of $|V{ub}|$. The advantage is that this input scheme is unaffected by the tension between inclusive and exclusive $|V{ub}|$ determinations (and the tensions between different exclusive determinations). Furthermore, with the most recent determination of $\beta$, the precision of the CKM elements is increased. The predicted value of $|V{ub}|$ in this scheme with the current flavio inputs is $$|V{ub}|=(3.72\pm0.09)\times 10^{-3}\,,$$ which has an error nearly two times smaller than the exclusive $V_{ub}$ determined from $B\to\pi\ell\nu$.

[DavidMStraub]

Is that beta from B to psi KS or something else?

[peterstangl]

It's mostly $B\to\psi K_S$ but also some other charmonium channels listed here: https://hflav-eos.web.cern.ch/hflav-eos/triangle/latest/#sin2b

[DavidMStraub]

But then it's no longer a tree-level determination, so not appropriate to use it in presence of dim-6 NP, or not?

[peterstangl]

But shouldn't the question be whether there might be a potential dim-6 NP contribution affecting the extraction of the CKM parameter, rather than whether the process is tree or loop level? Of course, in general, loop-level processes might be more affected by dim-6 NP than tree-level ones, but there is no real guarantee of that, right? And at the moment there are tensions in tree-level $b\to u\ell\nu$ data that could be interpreted in terms of dim-6 NP (e.g. https://arxiv.org/abs/2302.05268).

So, in the end, don't we always have to choose which dim-6 NP contributions we assume to be absent when extracting the CKM elements as used in the current implementation in flavio? And I'm not sure the absence of NP in tree-level $b\to u\ell\nu$ is necessarily better motivated than its absence in loop-level $B$ mixing.

In the end, could it make sense to implement the CKM extraction in the presence of dim-6 NP that we have in smelli in flavio to avoid this problem no matter whether tree or loop level observables are used?