Post 1.20: Ship clearly marked unstable builds

[Gadgetoid]

Following the launch of MicroPython 1.20 we'll have a new "stable" milestone to build our libraries against.

However it's quite likely- as we've seen with the unstable Pico W launch- that there will be significant changes/fixes to Bluetooth following its launch that customers will want in a build.

We will probably need keep up with these.

I think the solution is a new, empty, GitHub repository that just has some actions that grab and build Pimoroni Pico against the latest upstream MicroPython.

This will have the added benefit of failing CI when something significant changes, giving us early warnings of upcoming breaking changes.

I am, in fact, proposing actual Continuous Integration and nightly builds marked with commit short-hashes and build dates.

This sounds more complicated than it is. I promise 😆

[Gadgetoid]

Note: as an aside it would be nice to try and pare back some of the builds happening here.

Future, significant projects should probably live in their own repositories and that will take a bit of effort but the payoff in terms of being able to reason about our larger software projects, and make CI less noisy on PRs here should be immense.

Badger, Cosmic, Galactic and Inky MicroPython flavours should all probably have their own GitHub repository, builds, releases and documentation.

[Gadgetoid]

Some idea why our Pico/Pico W CMake builds are currently taking forever would be useful, too, I've a suspicion the CMake cache is just never updated or used.

Oh... yeah:

 Failed to save: Unable to reserve cache with key ccache-cmake-refs/pull/686/merge-99843b3c4facfd22bb67113cf586e2097fa8645b, another job may be creating this cache. More details: Cache already exists. Scope: refs/pull/686/merge, Key: ccache-cmake-refs/pull/686/merge-99843b3c4facfd22bb67113cf586e2097fa8645b, Version: 4ab6bfca68afab25f3f31f3c3bcab09fb3150d06fa631f765c8a4803c8e72347

[Gadgetoid]

Decided to do this with a PR against this repository for now - #906