Update Dockerfiles to fix compatibility issues.

[bcipriano]

Link the Issue(s) this Pull Request is related to.
#1196

Summarize your change.

• For Cuebot:
  • Newer JDK/JRE base images.
  • This runs natively on both x86_64 and arm64/v8 platforms.
  • This requires some dependency updates in Cuebot which will be done separately.
  • We'll want to upgrade Gradle further, but we're using a good amount of deprecated features in our build.gradle so that deserves a separate change.
  • We'll also want to upgrade our JDK further, but this image is as far as we can go without breaking Gradle. If this causes issues in the future we could try switching to a pure JDK image and use our own Gradle wrapper.
• For RQD:
  • Keep using the centos image for now. This provides a good base to build on for an actual deployment.
  • Add the --platform flag to force use of the x86_64 images. There are some issues using protoc on the ARM platform with Python 3.6.
  • We'll want to do some followup work to get upgraded to a newer Python version, both for its own sake and so we can run natively on ARM.
• For client-side Python libraries:
  • Switch to a Python 3.9 base image, more current and more in line with the current year VFX reference platform.
  • This runs natively on both x86_64 and arm64/v8 platforms.
  • Remove the build/deploy two-stage build. This doesn't really make sense for these images as they're never run directly from the images. In the deploy step we only copy the tarball to our preferred location, so the extra build stage just adds time for no benefit.
• For Python GUI apps:
  • Keeping using the CentOS image for now, with the older Python version. Add the --platform flag to force x86. We'll be stuck with this until we complete the PySide6 upgrade.
  • We could potentially switch to an x86 python image, but we're installing a lot of extra libraries to get the GUI stuff working so that's not worth the extra work now. We can revisit after the PySide upgrade.
  • Same as the other Python images, ditch the two-stage build, for the same reasons.

All the python images drop Python 2 usage for now. We still run unit tests against Python 2, but our packaging pipeline doesn't use it, and the newer dependencies are making it harder to maintain these images. We'll revisit once we start publishing PyPI packages.

Some of the dependency upgrades from #1185 are in here for testing purposes, those will be cleaned up once we merge that PR.

[DiegoTavares]

LGTM. I'm okay with dropping python2 on the images as we're still running the tests.