Ability to provide a jenkins URL for plugins

### Enhancement Type

Improve an existing feature

### Describe the enhancement

> Referencing this discussion:
> https://github.com/itzg/docker-minecraft-server/discussions/2273#discussioncomment-7219702

Some plugins distribute their JARs through Jenkins or other CI/CD platforms, distributed at the `/lastSuccesfulBuild/artifact` endpoint in the case of Jenkins:
> https://ci.citizensnpcs.co/job/Citizens2/lastSuccessfulBuild/artifact/

Unfortunately, sometime there's multiple artifacts in the build:
> https://ci.athion.net/job/FastAsyncWorldEdit/lastSuccessfulBuild/artifact/artifacts/

Even if there's only one artifact, you can't resolve the download link without giving the build number unless the project set a fixed name for the artifact because Jenkins doesn't provide a latest build endpoint that's version agnostic.

---

**Manually resolving**:

1. `/lastSuccesfulBuild/api/json` contains a filename key which points to the artifact
2. `/lastSuccessfulBuild/artifact/*zip*` provides a zipped archive with the following structure
> archive/foo/bar/plugin.jar
> `foo/bar` being the folder structure of the build

---

**Problems**:

Some plugins don't provide a clear latest endpoint as well, and uses their own CI/CD:
> https://apps.methodscript.com/builds/commandhelperjar/

---

**My workaround**:

I've added some bash logic that executes before the entry point, which is a bit lengthy because jq is not present in the base image.

```shell
entrypoint: >-
/bin/sh -c "
mkdir -p /data/plugins;
wget -q -O /data/plugins/commandhelper-3.3.5-SNAPSHOT-full.jar --backups=0 "$(curl -s "https://apps.methodscript.com/builds/commandhelperjar/" | grep -oE 'build-[0-9]+' | sort -V | tail -n 1 | awk -F '-' '{print "https://apps.methodscript.com/builds/commandhelperjar/build-"$2"%2Fcommandhelper-3.3.5-SNAPSHOT-full.jar"}')";
wget -q -P /data/plugins --backups=0 'https://ci.athion.net/job/FastAsyncWorldEdit/lastSuccessfulBuild/artifact/artifacts/'$(curl -s https://ci.athion.net/job/FastAsyncWorldEdit/lastSuccessfulBuild/api/json | grep -o '\"fileName\":\"[^\"]*jar\"' | head -n 1 | sed -e 's/\"fileName\":\"//' -e 's/\"$//');
wget -q -P /data/plugins --backups=0 'https://ci.citizensnpcs.co/job/Citizens2/lastSuccessfulBuild/artifact/dist/target/'$(curl -s https://ci.citizensnpcs.co/job/Citizens2/lastSuccessfulBuild/api/json | grep -o '\"fileName\":\"[^\"]*jar\"' | sed -e 's/\"fileName\":\"//' -e 's/\"$//');
/start"
```

_note: that the code above will make SPIGET_RESSOURCE fail, most likely due to creating the plugins folder manually_

---

**Enhancement ideas**:

1. (probably unsafe) Passing a bash sequence to mc-image-helper, which it'll evaluate in the context of computing a string, which it will expect to be a download link
2. (Jenkins only I think) Passing a sort of key/value format string where key is the Jenkins link (`https://ci.citizensnpcs.co/job/Citizens2`) and value being glob-style, like Citizens*.jar and it'll match to a file in the zip.
3. Re-using the same idea as above, perhaps providing directly the CI/CD json endpoint, and the glob formatted value, and it'll try to compute the download path

---

Thanks for considering this enhancement!

Start by reviewing the startup entry point and its mc-image-helper integration; the issue does not identify a repository file or test. Before implementation, agree on which CI/CD URL format and artifact-selection behavior to support, then define completion around resolving the selected plugin artifact without breaking SPIGET_RESOURCE.

Written by the indexing model from the issue text.