Bump base image to RHEL9 and Python version to 3.12

[komish]

Description of the change:

• Bump the base image used in ansible-operator's container image to use UBI9 (From UBI9)
• Bump the Python version to Python 3.12 (from Python 3.9)

Motivation for the change:

There's an active initiative to bump various software versions for the ansible-operator project to move it inline with the current state of packages that are available. This PR just focuses on bumping the UBI and be based off of RHEL9, and bumps the Python version at the same time to move away from the system's (image's) default.

The goal was to be as close to the original design as possible. Some changes to the underlying design were made with intention to minimize or simplify requirements.

Notes for reviewers

• UBI9 comes with python 3.9 by default, available at /usr/bin/python3. Python 3.12 is installed at /usr/bin/python3.12. For this reason, you'll see modifications here adding /usr/local/bin/python3, which will be linked to python 3.12 for our use cases. This is the recommended path in RHEL9 documentation.
  • The ansible_python_interpreter in tests needed to be adjusted for this reason.
• yum was swapped with dnf.
• pip is no longer installed via RPM, and is instead installed using ensurepip which is available in the standard library. This is due to the fact that it didn't quite make sense to install something via the RPM, and then use pip to update it.
• setuptools is not being installed, as it doesn't seem necessary for what we're doing.
• The base image phase no longer installs pip or pipenv, as those are transferred over from the builder image when we copy site-packages in my testing.
• I intend to keep pipfile.Dockerfile consistent with the contents of Dockerfile, though its existence is unclear to me.

[TrilokGeer]

Using PIPENV_SYSTEM=1 will require modifications whenever there is a conflict in the base system version packages. Nevertheless, closing #92 in favour of the better implementation here.

[komish]

@TrilokGeer I know I didn't remove it as a part of this PR, but just for the record - I 100% agree. In general, I think using system python may be an explicit choice for this project, but leveraging pipenv in this way complicates things in a way I don't like. I have this noted as something to address as well (as I saw you do in similar PRs).