Fix Successful Repro Pipeline Errors

[CodeGat]

This PR fixes a couple of errors found when a config successfully reproduces, namely:

• There was a comment saying repro had failed when it had actually succeeded, due to the wrong bash test being used. See https://github.com/ACCESS-NRI/model-config-tests/pull/56/commits/0b7b943fed9a3d819ad0379a34bedaa6df7799c3 (for PR CI) and https://github.com/ACCESS-NRI/model-config-tests/pull/56/commits/b71a244e2942cad2407a142d8369df906cd6056c (for Scheduled CI). See Failed Comment.
• The pipeline was allowing merging when the version hadn't been updated properly. This was because it was comparing release ('1.0') against dev (''), seeing that the versions were different, and allowing merging. We now check for '', not just null. See https://github.com/ACCESS-NRI/model-config-tests/pull/56/commits/89d6d6ce48c042fa5cd90972be244e10ef35b1f4 and https://github.com/ACCESS-NRI/model-config-tests/pull/56/commits/6a36a4cdecb9974232363eafefa9110e929e244c. See Workflow Log Annotation.

And fixes up some variables in comments:

• We were using ${{ needs.repro-test.outputs.artifact-url }} but that wasn't actually an output to that job, so it would be the empty string. Added it in https://github.com/ACCESS-NRI/model-config-tests/pull/56/commits/3ddef0d587bdcc4b8097e7f17b84a4d74812be1d. See end of PR comment https://github.com/ACCESS-NRI/access-esm1.5-configs/pull/86#issuecomment-2316792404
• Simplified the comment and issue bodies template variables in https://github.com/ACCESS-NRI/model-config-tests/pull/56/commits/39c2edf9f257b7c52fb06916d9021335e5956063 and https://github.com/ACCESS-NRI/model-config-tests/pull/56/commits/0bf1601028e04cdb623f5603cc0bac52f3d72977.

Linking failed PRs https://github.com/ACCESS-NRI/access-esm1.5-configs/pull/86 and https://github.com/ACCESS-NRI/access-esm1.5-configs/pull/87 Closes #57

[aidanheerdegen]

• The pipeline was allowing merging when the version hadn't been updated. This was because it was comparing release ('1.0') against dev (''), seeing that the versions were different, and allowing merging. We now check for '', not just null. See 89d6d6c and 6a36a4c.

Bugger. Now I remember we missed the step of merging the version from release back into dev.

Does the new logic mean we never have to do this? I don't think it's a good idea, so perhaps we should special case when the dev is null or empty but release has a version, and insist that the current version is added to dev?

[CodeGat]

I think that the solution is to have modified the version to 1.0 in the dev-* branch rather than the release-* branch. But then we'd still have to have added a boring commit to the trigger the on.push.paths=metadata.yaml anyway.

The real solution is to add another trigger to the version bumping stuff on the release-* branch: on.create, and check that it is a release-* branch.