Reorganize the rdf4j-util module: split into separate modules for easier dependency mgmt

[abrokenjester]

The @Experimental and @InternalUseOnly annotations are currently part of rdf4j-model-api. They were moved there (from rdf4j-util) as part of an effort to make rdf4j-model-api as lightweight as possible (and not have to include all the iterator and utility classes from rdf4j-util).

This has introduced a problem in the dependency hierarchy, in particular for rdf4j-util: it now has to depend on rdf4j-model-api, just to be able to refer to those two annotation classes. Note that even if we removed their actual use from rdf4j-util code, we'd still get api comparison errors, because those two classes no longer appear (making it binary incompatible).

We could move them back and make rdf4j-model-api depend on rdf4j-util again, but that increases its footprint again.

A better fix is to reorganize the rdf4j-util module, splitting it into separate "commons utilities" modules. That way the annotation classes can be moved back into a (leaner) commons module that rdf4j-model-api can then depend on again.

Possible new Maven structure (oer = org.eclipse.rdf4j):

• rdf4j-commons (POM only, contains submodules for various 'commons' functionality)
  • rdf4j-commons-utilities -> annotations and other classes (for which no more specific module can be found) for use throughout the rdf4j codebase. Intended to be as small as possible to decrease footprint.
  • rdf4j-commons-iterators -> everything in oer.common.iterator, oer.common.iteration and oer.util.iterators
  • rdf4j-commons-transaction -> everything in oer.common.transaction (at some point we'll migratate IsolationLevel there as well)
  • rdf4j-commons-io -> everything in oer.common.io and oer.common.net
  • rdf4j-commons-xml -> everything in oer.common.xml
  • rdf4j-commons-text -> everything in oer.common.text

Note that rdf4j-util would be removed. Effectively we get six additional modules, all relatively small. Downside is more modules to juggle, but possible upside is that it gives us more control when wanting to share functionality across the code base (especially when sharing code across both client and server). It also gives us a better handle on what code in that "catch-all" bucket is out of date and no longer used, and sets us up nicely for the goal of making sure each package is only in a single module.