Usually upstream releases the source packages src:pico-sdk and src:picotool
together in lockstep with the same version. To build most things with pico-sdk
you also need a picotool of at least that version. But building with picotool
(even though not very useful for most use-cases) can be disabled by setting
PICO_NO_PICOTOOL=ON in the cmake flags. To avoid a circular dependency between
the two source packages we do the following:

pico-sdk gets compiled with PICO_NO_PICOTOOL=ON to make sure that the sdk can
be built. Building with reduced functionality is no problem, because the
resulting binaries are not getting distributed. Instead, the pico-sdk-source
package ships source code in /usr/src/pico-sdk. Even though most uses of
pico-sdk-source need picotool, the pico-sdk-source package does not depend on
picotool -- it only recommends it. A hard dependency is not required because
technically (when building with PICO_NO_PICOTOOL=ON), pico-sdk-source can be
used just fine without picotool. Having picotool as a Recommends only is
required to not prevent building the new picotool.

The src:picotool source package cannot be built without the pico-sdk-source
build dependency of at least the same version. If the pico-sdk-source would
Depends instead of Recommends on picotool, then packaging new versions of
picotool would be made tricky and would require a bootstrapping step.

Since building with pico-sdk-source requires a recent-enough picotool, the
src:pico-sdk source package does not come with an autopkgtest to build
something with pico-sdk-source. If it would, that autopkgtest would fail when
compiling new versions of src:pico-sdk because the autopkgtest would need a
version of picotool that is at least as high as the version of src:pico-sdk and
that version cannot get uploaded to the archive before pico-sdk itself gets
uploaded. We want to avoid uploading pico-sdk with a failing autopkgtest. So
the test to compile a very small project using pico-sdk-source is in the
picotool source package.

So the order of packaging new versions of src:pico-sdk and src:picotool is the
following:

 0. (optional) package potentially new version of tinyusb
 1. package the new version of pico-sdk
     1.1 bump Recommends of picotool to the new version
 2. upload the new pico-sdk version and wait for the next dinstall with it
 3. while waiting, package the new picotool
     3.1 bump Build-Depends on pico-sdk-source to the new version
     3.1 bump Depends of the autopkgtest to the new pico-sdk-source version
 4. upload picotool to unstable after it was built and its autopkgtest ran
    successfully with the new pico-sdk in the archive
