Qubit spectroscopy + flux

[alecandido]

In #839, it was proposed to add an optional flux pulse to a regular qubit spectroscopy.

This could be suboptimal for Qibocal, as it is complicating a bit a very basic routine. But even creating a routine that's almost a copy-paste is not a very appealing plan.

Moreover, one of the main use of the routine was scanning flux in a few points (instead of a full qubt flux dependency), and possibly scanning amplitude at the same time.
This meant having a simpler 1D scan run repeated a few times, in an informed way (possibly driven by experience), to replace a more expensive higher-dimensional sweeper.

While this could be more or less useful, there are a couple of considerable drawbacks:

1. it is trading computer time (larger automated scans) for human time (repeating smaller scan multiple times)
2. it is hindering knowledge accumulation - as the decision of further steps is always in charge of the person writing the runcards and running (with experience passed mostly as word of mouth)

The proposal in this issue is to replace this PR by exploiting two features of Qibocal, a recent one (scripts #869) and a forthcoming one (protocols extension #508).
In this sense, I'm not even that much interested in the protocol's inherent advantages, but rather in the approach to the protocols' development process.

After the rationale...

Factual proposal

The idea is to create a script that will do the bisection, or whatever other algorithm, in a single run, producing a single report.

This would already be possible on its own, but you'd still need to have a frequency-scanning acquisition supporting a flux pulse.
Since this may not be of general interest, and it may not be worth to maintain in Qibocal, instead of keeping it in a branch this could be a standalone project developed in a separate repository of extra protocols (either in qiboteam organization, or in a private repo).
This would provide better management and visibility, without adding anything to the maintenance cost of Qibocal itself.

For this last part, #508 will be needed, but I can implement very quickly it whenever it's needed.

[alecandido]

@DavidSarlle I'd propose you to attempt translating your code according to the plan above (if you like it). I can provide some help, both in scaffolding the repo and using the new API.

There is no need to rush, just let me know when you'll be ready, that I will try to schedule #508 asap.

Since #839 is not going to be merged anyhow, and now there is a plan to go further, I'm closing the PR as replaced by this issue.