Add module-info.java in `org.obographs` namespace

[julesjacobsen]

We need to start migrating obographs to enable more modern java applications to fully embrace the benefits of the module system.

See the Java tutorial: https://dev.java/learn/modules/intro/

Regarding module name uniqueness, the recommendation is the same as for packages: Pick a URL that's associated with the project and invert it to come up with the first part of the module name, then refine from there. (This implies that the two example modules are associated with the domain example.com.) If you apply this process to module names and package names, the former will usually be a prefix of the latter because modules are more general than packages. That is by no means required but an indicator that the names were chosen well.

@cmungall this name should be immutable, once chosen. You've been suggesting a move of the repo somewhere outside of the genenontology organisation, so how about making a dedicated obographs github organisation where all the obographs projects can sit - i.e. docs and reference implementations?

The module name for this project would naturally lend itself to be org.obographs so that the core library would have the module org.obographs.core

This would also ideally require a change of the package structure to match this i.e. change from org.geneontology.obographs to just org.obographs. This is a breaking change, but not one which would be too disruptive.

[ielis]

Please note one technical detail. Maven will not allow us to deploy under org.obographs group ID unless we own the domain.

If we go for a github orgainsation, we'll end up having something like HTSJDK:

<!-- https://mvnrepository.com/artifact/com.github.samtools/htsjdk -->
<dependency>
    <groupId>com.github.obographs</groupId>  <!-- NOT org.obographs -->
    <artifactId>obographs-core</artifactId>
</dependency>