ci: Fix broken CI for ASWF 2021 and 2022 containers

[lgritz]

Identical in spirit to the coresponding PR for OpenImageIO.

The background here takes some explaining...

The ASWF's prepared Docker containers that reproduce a CentOS7-based environment corresponding to VFX Platform 2021 and 2022 years contain a glibc that is too old to run a newer version of "node" -- which GitHub Actions themselves use. The old one is no longer receiving support, and GitHub finally changed the policy that was allowing its GHA runners to still run the old version that worked with those ASWF containers. The new node version that is happy on the GHA runners requires a glibc newer than the one in the containers. So that breaks all our CI runs in 2021 and 2022 VFX Platform configurations.

See this thread, if you dare:
https://academysoftwarefdn.slack.com/archives/C0169RX7MMK/p1732574400981949

Anyway, Jean-Francois Panisset proposed and tested a fix, which lets us continue working (for now) by downloading an old node implemenation (which is happy with the old glibc) and installing it atop the conainers, so it's this old one that the GH actions will use. It feels like it's all held together by chewing gum and duct tape, but it unbreaks our CI and hopefully it will keep working until all the studios have switched fully to RHEL/Alma/Rocky 9.x and we no longer care about testing on CentOS-7 based containers or supporting the VFX Platform years that are too old to be relevant to the new OS that the studios are using.

[lgritz]

Review would be appreciated, but even without it I will merge shortly, since without this patch, CI will be broken for all PRs.

[aconty]

I'm not familiar with GH ci setup, but it all looks reasonable. I was going to approve but thought to wait for better eyes.

[lgritz]

The most important thing about a review is just a second pair of eyes to confirm that the description of what I'm doing seems like a reasonable approach and the code appears likely to be doing what's described, and a sensible person can't easily think of a vastly better approach to the problem.

Secondarily, that I haven't botched it in some weird way like accidentally including a totally unrelated set of changes in the commit, or accidentally deleting the workflow and that's why it passes now. And, of course, that this isn't a malicious patch sent by somebody impersonating me.

Any kind of line-by-line deep understanding is more than I expect in most reviews (and I'll ask for that explicitly when I think something tricky or high risk is going on), especially for something like this PR which only is modifying the CI setup and can't possibly break users, and it obviously goes from failing tests to passing.