trapme: Inappropriate `CUSTOMIZED_SDK_URL` set when `SDK_RESOURCE` is not `customized`

This came to me in bed while I was failing to sleep last night as another item which fits in with the other [trapme](https://github.com/adoptium/aqa-tests/issues?q=is%3Aissue+trapme) ones I've raised so I felt it was worth documenting as I've hit it quite a few times.

If all of the following parameters are defined:
- `CUSTOMIZED_SDK_URL`
- `UPSTREAM_JOB_NAME` (likely irrelevant but included for the test)
- `UPSTREAM_JOB_NUMBER` (likely irrelevant but included for the test)

There can be undesired consequences based on the value of `SDK_RESOURCE`:
- If [SDK_RESOURCE=releases](https://ci.adoptium.net/job/Grinder/8401/console), CUSTOMIZED_SDK_URL will be used (Search `get jdk binary` in the log)
- If [SDK_RESOURCE=nightly](https://ci.adoptium.net/job/Grinder/8402/console), I think CUSTOMIZED_SDK_URL is also used, although it didn't seem to succeed in my test - https://github.com/adoptium/aqa-tests/issues/4890 is probably relevant
- if [SDK_RESOURCE=customized](https://ci.adoptium.net/job/Grinder/8403/console) it works as expected
- if [SDK_RESOURCE=upstream](https://ci.adoptium.net/job/Grinder/8404/console) it also seems to use the CUSTOMIZED_SDK_URL

While this is partially described in the description of `CUSTOMIZED_SDK_URL`:
```
Customized SDK url, need to set when SDK_RESOURCE=customized
For Openj9 nightly from artifactory, please provide URL upto the SDK job name, the Grinder will download the latest SDK
SDK_RESOURCE=nightly
CUSTOMIZED_SDK_URL=https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Build_JDK8_x86-64_linux_Nightly/
CUSTOMIZED_SDK_URL=https://openj9-artifactory.osuosl.org/artifactory/ci-openj9/Build_JDK17_ppc64le_linux_Nightly/
```
it's not obvious from the logs that it's gone down this special case, and one use case that can trip you up is that if you "re-run" a job that had a `CUSTOMIZED_SDK_URL` set and change `SDK_RESOURCE` to "releases" in a re-run (to verify the test against the last Temurin release) and forget to switch out the SDK_URL (Note that the description above is not on the SDK_RESOURCE field) then you can end up running something you didn't expect to.

I'm not certain what the real solution is here, but some options:
- Add doc to SDK_RESOURCE to point at the message in the CUSTOMIZED_SDK_URL field
- Make sure we only do the processing described in the note on SDK_RESOURCE=nightly and not the other options
- Maybe don't trigger that logic unless JDK_IMP is `openj9` unless there are other use cases for it (Or the reverse - don't trigger that logic if it's hotspot - or do we have valid reasons for that which wouldn't be better servied with a customized URL?)
- Given how this is intended to be use can we trap the case where it's not a job link, but is a straight `tarball` in the `CUSTOMIZED_SDK_URL` field in this specail situation, which is presumably never desirable?

Start with the SDK_RESOURCE and CUSTOMIZED_SDK_URL handling used by the Grinder job, reproducing the releases, nightly, customized, and upstream cases. Search the console logs for “get jdk binary” and compare the nightly behavior with issue #4890. Done should clearly prevent an unintended customized URL from being used, or document the intended exceptions.

Written by the indexing model from the issue text.