[FOLIO-4126] Extract MD logic, minor other improvements

[ncovercash]

This PR does the following:

• Remove a few uses of environment variables where they were redundant, instead using GA's builtin step output;
• Cleaned up a few conditions to use GA directly instead of shell evaluation;
• Added --update-snapshots to the main "build" step, to ensure that the latest snapshots are always used (performance penalty of <1s with multiple snapshot dependencies in my testing);
• *Moved sonar logic from build to a separate job; and
• *Moved MD updating logic to a separate job.

The two changes marked with * are done to improve parallelization, to decrease the time between CI starting and docker/publication completing. They also significantly decrease the number of parameters flying around. Here's what was extracted and why:

already merged

- Sonar does not need to block Docker/etc steps from completing. It's also pretty slow (often a minute-plus), so having it block everything is quite a pain. - Sonar relies on the compiled `class` files and Jacoco results, and for some repositories, `generated-sources` and friends

• The MD getting logic (step with all the jq magic) requires artifact-version.
  • This comes from the version-number step (which takes ~15s to resolve for some reason?), and is the only thing which directly relies on it. By moving this logic from the main build step, version-number and build can run concurrently.
  • It's a little goofy having a job which only really has one "actual" step; I considered integrating the MD updates directly into the version number calculation, but that seemed a bit too far.
• To provide these, I created a new artifact build-artifacts which is target/* (excluding API docs + jars). This is useful for debugging in general, but allows downstream steps access to all of this without needing to re-run maven. In testing this was ~2MB across a few repos, so it's quite minimal.

---

It got a little more spaghetti, but in total this shaved about 60-90 seconds off:

Original:

New:

[ncovercash]

this could almost certainly also be updated into a check of hashFiles, but I'm not sure which would be clearer

[ncovercash]

This has the bonus of GA showing the step 'skipped' iff the file already exists

[ncovercash]

I'd dynamically rename the job itself, too, but I'm wary of potentially breaking branch protection rules. It should be fine since do-docker-push=true only when we're on main or we're on a release tag, so it'd always be simply Docker build on PRs; thoughts?

[dcrossleyau]

I do not understand the benefit of dynamically renaming the job. Feels like too much magic.

[ncovercash]

To prevent the confusion of seeing a step named "docker build and publish" having ran in a PR run, even though no publishing occurred

[ncovercash]

@dcrossleyau now that #97 is merged, I went ahead and synced this PR with the base branch to make it a little less noisy