Merging changes into release/0.18

This is kinda sorta a cherry-pick of !173 (merged).

A branch named trusted-development appears to have been created roughly 6 weeks ago with 910cf7ca. Since then, several different MRs have merged into trusted-development.

trusted-development was merged into master at several points, including 404b37da (!143 (merged)), bb17b0a6 (!147 (merged)), and 085e46e7 (!173 (merged)). All of these merges happened after the creation of the release/0.18 branch. However, the first two merges were presented as MRs to be cherry-picked into the release branch, and they corresponding were -- carrying with them the commits from all the MRs that had fed into the trusted-development branch as of that point.

However, bdf2e614 (!150 (merged)) merged release/0.18 into trusted-development, and the twenty or so MRs since then have all built on the release branch code. Now, trusted-development has been merged into master by way of 085e46e7 (!173 (merged)), which has merged the release/0.18 branch back into the master branch.

This is a different kind of setup than other OSDU projects. Normally, MRs merge into master and are cherry-picked into release branches if necessary. I had not seen that it was set up this way during the first two cherry-pick creations, but they roughly worked because the content in trusted-development at the time was not present in the release branch, nor was the release branch present in it.

Now, this "cherry-pick" would include commits that are already based on release/0.18. It feels strange to apply a cherry-pick in this case -- it would double the commits and not introduce any difference -- normally the cherry-pick process keeps the same code delta, but has a different basis commit. This would have the same for both.

Therefore, it makes more sense to me to do a simple merge of trusted-development into release/0.18, then follow up with a tag. This should have the combined content of the 20-ish MRs that merged into trusted-development between !150 (merged) and !172 (merged).

Note that trusted-development and master are identical as of the merging for !173 (merged), and so this will make the release branch identical as well. Normally, we keep them separate because artifact versions are committed to the branch -- edits to pom.xml files or VERSION files. However, I don't see anything here that resembles version data, so I think it is ok.

So, while I think this is a good MR that will result in the correct answer for tag 0.18.1, it is definitely a little suspect and worthy of further scrunity. Sometime soon, we should review the branch and merge theory used by this project and either adjust the release scripts to account for this way of working or adjust the way of working to account for the release scripts.