#399 #468 #221 Upgrade to Eclipse 2023-03 with in-place upgrade

General info on merge request:

• This upgrades from Eclipse 2022-06 to 2023-03. See the individual commits for details. Best reviewed per commit.
• You can set up a new development environment from scratch, but you can also in-place upgrade your existing development environment now. See the dependency-upgrades.asciidoc file for the instructions. It would be nice if you could all try that out, so that we can mature the instructions listed there. In this particular instance, you need to remove the 'Tycho Project Configurators' manually, if you have them still in your development environment. See the step-by-step instructions for details.

Some issues I had while trying out the in-place update. I was trying things out and did not use the step-by-step instructions as they are now, so hopefully you will not encounter them, but it would be good if you could try, to see how 'stable' and in-place update is in practice:

• When pressing 'Ctrl+Shift+T' for 'Open Type' I at some point had two commands associated to it. I restored all default keybindings to resolve this.
• Using the 'Open Type' dialog and choosing a class from the JDK led to errors like: Type 'java.lang.String' could not be found in '.org.eclipse.jdt.core.external.folders/.link23/jre/lib/jrt-fs.jar'. Make sure all workspace resources are refreshed.. A workspace refresh and full clean/rebuild did not resolve this. I solved it by removing all projects from my workspace and re-importing them.
• Commiting the provisioning operation (for P2 or target platform) by Oomph would fail with java.lang.ClassCastException: class org.bouncycastle.openpgp.PGPPublicKey cannot be cast to class org.bouncycastle.openpgp.PGPPublicKey (org.bouncycastle.openpgp.PGPPublicKey is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @685f5d0d; org.bouncycastle.openpgp.PGPPublicKey is in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @4e2f2438). I resolved this by updating the Oomph version in my development environment: 'Help' -> 'Check for updates...', which only listed Oomph updates, and then 'Next' -> 'Next', accepting all licenses, 'Finish', 'Select all' -> 'Trust selected' -> 'Restart Now'.

Important further details on the changes, some of which affect our way of working into the future:

• I got rid of the Apache XML serializer specific version pinning that was needed for the previous Eclipse version. However, I also got rid of that dependency altogether later on (see next point).
• I had quite some issues with getting Apache Xalan, Apache Xerces and Apache XML resolver to work properly. They were complaining about missing Import-Package dependencies. The packages were JDK packages, so should always be present. I spent hours on this, but didn't manage. Then I realized that (probably about a decade ago) I introduced them as the XML functionality of the JDK itself at that time wasn't working. But we use much newer JDKs now, so these dependencies are no longer needed. I thus reduced the dependencies and no longer needed code/comments related to them. This also fixes issues with saving SVG files from the SVG viewer/visualizer to paths with characters that get encoded as special characters in URLs, such as spaces. This issue is unresolved for Apache Xalan, but my tests show that the JDK implementation handles this properly.
• I added the Eclipse PDE runtime (with 'Plug-in Registry' view) to the product, to enable debugging of dependency problems.
• The version of org.apache.commons.lang3 got updated, deprecating its StringEscapeUtils. The class essentially got moved to org.apache.commons.text, but that is not available on Orbit, nor in the Eclipse 2023-03 update site. Eclipse Platform and its projects are now using dependencies directly from Maven Central, if they are available there, and have proper OSGi metadata in their manifest (see here, here and here). In fact, they plan to no longer update or add such dependencies to Orbit at all, in the future (see here). Hence, it makes sense that if we need additional dependencies, that we go the same route. Eclipse PDE and Eclipse Tycho both support target platforms with Maven targets. However, Oomph does not. We therefore can no longer generate our target platform using Oomph, and have to switch to a manually crafted target platform. This has the additional benefit that there will be less unneeded 'crap' in the target platform. I implemented this change, removing target platform generation from the Oomph setup, and I manually cleaned up the target platform. It is still possible to let Oomph reactive the target platform, after having edited it. This works in the same way as previous we generated a new target platform using Oomph. The Oomph task has a slightly different name, but is named in such a way that it is clear which one to use. You can also just open the target platform file and pressing the 'Reload Target Platform' button at the top-right of the 'Definition' tab.
• Since our previous Eclipse upgrade, I get a lot of info-level items in the 'Problems' view when opening XML-based files that don't link to their schema. I configured Wild Web Developer's XML tools to ignore such 'issues'.
• We have M2E settings in our development environment configuration (set by Oomph) to ignore missing M2E lifecycle mappings. However, I still got some, and thus explicitly ignored them in pom.xml files.
• The Eclipse JDT compiler tool is no longer provided as a plug-in fragment, but is now provided as a regular plugin. Hence, we don't need special configuration for it anymore for our Maven build. See also here.
• When upgrading to Eclipse 2022-06, we had to ensure all projects have a project-specific encoding, or projects would get a warning. How, this can be configured to be ignored (see here and here). We already configure the global encoding in the Eclipse ESCET product, so there is no need for project-specific encodings. Especially for projects of the user, this was annoying. Also, the changes we previously made to ensure the CIF examples and benchmarks had no such warnings (see !331 (merged), comment 828762), are no longer needed, and I thus reverted them.
• The development environment now contains Maven 3.8.7, but the Eclipse Foundation Jenkins servers only have 3.8.6, so they don't match, but hopefully that is not a big deal.

Other issues resolved by upgrading to a newer Eclipse version:

• The SVG viewer/visualizer 'Save as' dialog now properly starts in the right initial proposed directory. This fixes #221 (closed).
• We can now use records in our Java code without getting warnings about JavaDocs.

Remaining issues:

• We now require PGP signing, for the dependencies we take directly from Maven Central. This requires a PGP key that we have to request from the Eclipse IT team, so I'll do this in a separate isuse.

Closes #399 (closed) #468 (closed) #221 (closed)