Cache reusal foreseen problems when using git repositories (coreboot-git now being example)

Just some notes trying to fix #1417 with #1449

Context:

• it seems that coreboot release tarballs are getting less and less used as opposed to use different forks and specific commits. I have no specific opinion about that, but the buildsystem was not thought to be doing that up until now
• nitrokey and purism are expecting some kind of exclusive usage of the coreboot-git build directory per architecture, but need to switch fork and use a specific commit doing that, getting rid of the artifacts in the directory that is not linked to the git repo
• by doing so, we currently get rid of build artifacts, which makes caching of CircleCI less relevant, since we use workspace caches between boards to minimize rebuilding where adequate

The current build system takes into consideration for coreboot/linux modules that:

• it is possible to store "objects" in $(BOARD) subdir of the module build dir. This is invalidated as of now since when calling git clean, those directories are wiped.
• We could move those modules related object directories back to build/arch/module/$(BOARD) so that cleaning doesn't wipe them

More thinking needed to dodge the problem. We will see once first, the builds reusing coreboot-git works, and then rebuilding such build from cache and seeing the impact of the wiping of those board related object directories. If the cost is higher, compared to coreboot tarball based builds, this will need to be dealt with higher priority.

Start with issues #1417 and #1449, then inspect the build system's handling of coreboot/linux modules, git clean, and CircleCI workspace caches. Compare cache reuse and rebuild behavior for coreboot-git builds, including whether board-related object directories are wiped; the required design is not yet settled.