KAFKA-19768: Update ci-complete to support branch 4.0 buildscan upload

[mingyen066]

Currently, if we merge to the 4.0 branch, the CI workflow in branch
4.0 will be triggered. After the 4.0 CI finishes, it triggers
the ci-complete.yml workflow in the trunk branch. However, the
JDK version, Gradle version and the names of the build scan files
differ (due to
KAFKA-18748), so
the trunk ci-complete.yml cannot find the correct BuildScan files
generated by 4.0 CI workflow to upload to Develocity.

To address this, I added a job in ci-complete to first retrieve all
BuildScan file names that start with build-scan-, then create a job
for each file, extract the java version from the name, and finally
upload the corresponding BuildScan. The reason I chose not to detect the
target branch is that this information cannot be obtained from the
GitHub environment (see details in JIRA
KAFKA-19768).

There is a potential issue with using Gradle 9 to upload Gradle 8
buildScan archives to Develocity, I am not sure if it will work because
I don't have access to a Develocity server to test it. I could only find
the compatibility table for Develocity plugin and Gradle versions.
https://docs.gradle.com/develocity/compatibility/#build_scans

I have tested this in my forked repo. There are two ci-complete runs
in the following, one for the trunk build, and the other for a PR
merged into the 4.0 branch. Each run can obtain its corresponding
BuildScan
files and execute them. The Gradle task buildScanPublishPrevious fails
as expected due to the lack of a Develocity access token.

• https://github.com/mingyen066/kafka/actions/runs/19000866672
  • Found: ["build-scan-25-noflaky-new","build-scan-17-noflaky-new","build-scan-17-flaky-nonew","build-scan-25-flaky-nonew","build-scan-17-noflaky-nonew","build-scan-25-noflaky-nonew"]
• https://github.com/mingyen066/kafka/actions/runs/18999744250
  • Found: ["build-scan-quarantined-test-23","build-scan-quarantined-test-17","build-scan-test-23","build-scan-test-17"]