Convert the cachi2 image to a multi stage docker build

[eskultety]

The motivation behind this PR stems from the following:

1. ever since we started pre-installing Go SDKs into the images the image size grew out of hand (>2x)
2. the injected Go SDK installs make it impossible (among a couple of other blockers) for cachi2 itself be hermetically built because we'd have to come up with an ugly mechanism to prefetch the Go SDKs to be injected into the final image
3. slow image builds due to the size of the Go SDKs that had to be downloaded each time; this is particularly annoying with running integration tests locally since the image is rebuilt with every commit when run in an interactive rebase EDIT: Tests have shown that the RPM layers in a multi-stage scenario are rebuilt every time, so ^this issue will only be alleviated only slightly
4. we have an artificial dependency on nodejs via the js-deps directory which was only ever meant to be a build aid to make sure that: a) we're working with new enough Node that ships with corepack b) we're enabling and hence installing the correct Yarn version (v3) in the final image (Note: Yarn installation needs a namespace not to create artifacts on the global level for which we used the js-deps directory)
5. Installing cachi2 and all its dependencies via pip to the global pip module store as root (i.e. /usr/lib)

Depends on: https://github.com/containerbuildsystem/cachi2/pull/528

Maintainers will complete the following section

• [x] Commit messages are descriptive enough
• [ ] Code coverage from testing does not decrease and new code is covered
• [ ] Docs updated (if applicable)
• [ ] Docs links in the code are still valid (if docs were updated)

Note: if the contribution is external (not from an organization member), the CI pipeline will not run automatically. After verifying that the CI is safe to run:

• approve GitHub Actions workflows by clicking a button
• approve the Red Hat Trusted App Pipeline container build by commenting /ok-to-test (as is the standard for Pipelines as Code)

[eskultety]

Since v1:

• pinned the language base image versions to exact version strings (no digests though because we don't care about the underlying platform changes, we only care about the language installations and their data which are bound to be static based on the release they're tracking)
• bumped the NodeJS engine version to 22.3 (latest) because NodeJS 16 (default on Rocky/RHEL) has been EOL for a long time and corepack tends to drop support for old engines leading to various crashes (either in corepack or its shims, e.g. Yarn), IOW if we copy the corepack installation from a language base image we need to make sure we also copy the NodeJS installation it is being shipped with in the official image to ensure smooth compatibility (see commit 1)

[eskultety]

Rebased on top of main.