Improve reproducibility and traceability of builds
An issue that came up recently in conversation with @MagneFire was that currently, it's hard to track changes making it hard to find issues whenever they appear.

A build for a particular watch on a particular date is spread over eight different top-level repositories:

• asteroid
• meta-asteroid
• meta-asteroid-community
• meta-openembedded
• meta-qt5
• meta-smartphone
• meta-smartwatch
• oe-core

Most of those, in turn, pull in multiple different subrepositories. So if a change somewhere has caused a problem, it's not always very obvious how to go about finding which change is responsible. An example is this: #94

Potential solutions

1. Don't use AUTOREV instead use fixed commits and update them manually or automatically.
2. Use labeled branches to quickly test older versions (ex. After Yocto base changes, changes affecting many components)

Describe the feature you'd like
As mentioned in https://docs.yoctoproject.org/test-manual/reproducible-builds.html the goal is to make sure that

a given input build configuration will give the same binary output regardless of when it is built (now or in 5 years time), regardless of the path on the filesystem the build is run in, and regardless of the distro and tools on the underlying host system the build is running on.

If, for example, we know that a build of a particular watch worked at one point and failed at some later date (e.g. like this: #260 ) it would be very useful to quickly figure out which change induced the problem.

Additional context
Having reproducible builds is a useful step toward having CI/CD testing of changes and may also help with issues like this: #224