[Jenkins-infra] Per-plugin processes on ci.j.io

[Daniel Beck]

I'm planning to add additional information about plugins to the plugin site, such as license, test code coverage, their use of deprecated APIs, etc. (If this looks similar to a proposal from FOSDEM two years ago, it's not a coincidence.)

Two basic approaches to gather this information seem viable:

- Do it in one batch process, similar to how we build the Javadoc site today.
- Do it in lots of tiny processes, similar to CI builds.

I prefer the latter approach, as that seems better suited for this task: It can be more up to date (potentially started whenever master changed), and would not waste time working on unchanged plugins (which will likely be 95+% at any given time).

The plugin site consumes files with plugin metadata -- currently mostly the JSON files from updates.j.o. Any additional metadata would be provided as such, and we can probably store them on reports.j.io (where for example the core Jelly taglib already lives).

Here's the problem: It's unclear to me how to properly implement this on ci.j.io. We have a CI setup there we _could_ reuse to generate some metadata (Jenkinsfiles with buildPlugin() from jenkins-infra/pipeline-library), but these plugins are in the minority -- and having specific metadata about plugins tied to the presence of a specific CI build seems unnecessarily restrictive. Additionally, the security model for ci.j.io wouldn't like the presence of credentials, even if just for the reports.j.io host.

What would be the preferable approach for this on ci.j.io?