Review build labelling convention for `alpine-linux` agent build labels

Noting that https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk17u/job/jdk17u-alpine-linux-x64-temurin/393/ and the equivalent on other versions appears to insist on running on one of the equinix dockerhosts at the moment as it's looking for `build&&alpine-linux&&x64&&dockerBuild` - we'll need to think about that labelling convention ...
```
23:30:52 [NODE SHIFT] MOVING INTO DOCKER NODE MATCHING LABELNAME build&&alpine-linux&&x64&&dockerBuild...
[Pipeline] node
23:31:07 Still waiting to schedule task
23:31:07 ‘[dockerhost-equinix-ubuntu2204-x64-1](https://ci.adoptium.net/computer/dockerhost%2Dequinix%2Dubuntu2204%2Dx64%2D1/)’ is offline
23:59:27 Running on [dockerhost-equinix-ubuntu2204-x64-1](https://ci.adoptium.net/computer/dockerhost%2Dequinix%2Dubuntu2204%2Dx64%2D1/) in /home/jenkins/workspace/build-scripts/jobs/jdk17u/jdk17u-alpine-linux-x64-temurin
[Pipeline] {
```

_Originally posted by @sxa in https://github.com/adoptium/infrastructure/issues/3352#issuecomment-1920216207_

It seems that unless the build dockerhost has `alpine-linux` in the labels (which is misleading - it's not alpine - the alpine builds cannot be scheduled on it. We should look at whether there is a more sensible way to do this. Noting that I temporarily enabled the equinix machine which has this label in order to allow the builds to progress tonight.

Start by reviewing the referenced jdk17u-alpine-linux-x64-temurin CI job and its node-matching log, then compare the equivalent jobs for other versions. The work is done when the label convention lets Alpine builds schedule on appropriate hosts without relying on a misleading alpine-linux label.

Written by the indexing model from the issue text.