Use GHA cache for yocto sstate and shared downloads

[klutchell]

The current shared NFS cache is insecure as any workflow using our
self-hosted runners has full access to all cached files, including
private device types and sources.

This change drops the NFS in favour of GitHub built-in cache features.

These cache entries are very large, near the maximum 10gb size,
so they don't last very long in testing. A day or two.

However, it means we don't have to maintain a gigantic shared
cache and clean it regularly. But we will still sometimes
get some faster builds with cache-hit.

We could also run a local S3 or NFS instance on the self-hosted
runner stack to get more than 10gb of cache storage, but we will have
the same issue with permissions being too open to all workflows
unless we switch to a public cloud that supports OIDC.

Change-type: minor

[klutchell]

Last test results: https://github.com/balena-os/balena-yocto-scripts/actions/runs/10927276022/job/30333070956?pr=351

• Sync downloads cache: 0s (not found)
• Sync sstate cache: 0s (not found)
• Build: 1h 19m 25s
• Sync sstate cache: 2m 27s

  Cache Size: ~4395 MB (4608746647 B)
  Cache saved successfully
  Cache saved with key: yocto-sstate-generic-amd6[4](https://github.com/balena-os/balena-yocto-scripts/actions/runs/10927276022/job/30333070956?pr=351#step:74:4)
  

• Post Sync downloads cache: 5m 29s

  Cache Size: ~9285 MB (9736044847 B)
  Cache saved successfully
  Cache saved with key: yocto-downloads-generic-amd6[4](https://github.com/balena-os/balena-yocto-scripts/actions/runs/10927276022/job/30333070956?pr=351#step:75:4)
  

• Total: 1h 31m 11s

[klutchell]

Last test results: https://github.com/balena-os/balena-yocto-scripts/actions/runs/11630209275/job/32388667813?pr=351

• Cache not found for input keys: yocto-downloads
• Cache not found for input keys: yocto-sstate-genericx86-64-ext
• Build:
• Post Sync sstate cache:

• Post Sync downloads cache:

• Total:

[klutchell]

Superseded by #443