feat(release-it): tweak template to be common pipeline amenable

As noted in #94 (closed), release-it was not yet present in the common pipeline which was a blocker of the vision of "OpenAPI client generation releases are zero-configuration". #94 (closed) also noted that not much had to be done to add release-it to the common pipeline.

Gate the release-it jobs behind the presence of a .release-it.json file in the root of the repository. This should have zero effect on current users since that file needs to be present in order to use release-it. Guard against inadvertent triggering by allowing jobs to be explicitly disabled via a RELEASE_IT_DISABLED variable.

To guard against future namespace clashes, namespace all the release-it jobs. In #94 (closed), it was originally suggested that the USE_MERGE_REQUEST_RELEASE_FLOW variable could be namespaces and given the backup value of USE_MERGE_REQUEST_RELEASE_FLOW to avoid breaking clients but, upon reflection, having two variables controlling this behaviour adds more confusion than it prevents. As such, leave the variable un-namespaced as an interesting historical remnant.

Closes #94 (closed)

Testing

https://gitlab.developers.cam.ac.uk/uis/devops/experiments/rjw57/misc/-/pipelines/654270 is an example of a pipeline for a branch which a) does not explicitly include the release-it template but b) does have a .release-it.json file in the root. The release-it:update-release-merge-request job was correctly created.

https://gitlab.developers.cam.ac.uk/uis/devops/experiments/rjw57/misc/-/pipelines/654271 is an example of a pipeline for the same branch but where .release-it.json is not present. The release-it:update-release-merge-request job was correctly skipped.

The only significant change from this MR is to add release-it to the common pipeline and to tweak the rules so I think this exercises the required behaviours.