Simplify caching mechanisms for CI and PROD images

[potiuk]

For a long time we had used a sophisticated mechanism to speed up
our CI jobs by building the images in "pull_request_target" workflow
and pushing them to GitHub registry. That however had several drawbacks:

• CI image was complex when it comes to layer setup (we had to pre-
  cache installed dependencies by installing them from branch tip

• The pull_request_target is a very dangerous workflow, we had a number
  of security problems with it (and it's difficult to debug)

• Caching of pip and uv was not used because it increased size of
  the image significantly

This PR significantly improves the caching mechanisms for the images
building of several advacements that were not possible before:

• The upload-artifacts@v4 action and improved stash action developed
  by @assignUser and published in "apache/infrastructure-actions"
  allows us to store all images (8GB per run) in artifacts rather
  than in registry - so we can do the image build once and share
  it with all the jobs.

• The uv speed is "enough" to allow occasional installation of Airlfow
  locally. This allows to utilize cache-mount and locally build uv
  cache, rather than rely on "remote" cache when we are building
  local images for breeze. The first time you build local breeze
  image it will take 2-5 more minutes (depending on your network
  speed, but because we can utilise cache mounts, every subsequent
  build should be very fast - even if all dependencies change. Using
  uv also allows to "always" reinstall airflow when you build the
  image even if single source file changed, because with cache
  it takes sub-seconds to reinstall airflow and all dependencies.

• the cache mounts are not included in the image size, and since we
  can export and import images in CI in artifacts and we do not
  need to rebuild them, the images shared as compressed artifacts are
  relatively small (2GB) - cache of uv is around 4GB on top of that
  so sharing image built in the "build image" job with other jobs
  in the same workflow is fast.

• we are still using registry cache for the "non-python" parts of
  the image - both CI and breeze image build speed benefit from using
  the image cache for system dependencies, database clients etc.

Fixes: #42999
Fixes: #43268

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[gopidesupavan]

Nice looking forward for this :)

[potiuk]

cc: @assignUser -> will need an option to restore several keys in a single action for that. You might see some people from our team contributing to the stash action of yours :)