…ject.

Currently, project version info is passed in via a `versionTag` env variable,
which is only specified in the Github workflow environment.  Consequently,
`project.version` ends up being `null` when run locally.  This causes
weirdness for tools that expect a valid version number.

This change switches the project to use the axion-release plugin, which
determines the project version by looking at the git repo's tags.

Along with that switch, I've moved the project group and version
specification into the root build.gradle allprojects {} such that
these values do not need to be specified in each sub-poject.

I also did some related clean-up for our jitpack configuration (and
Maven repository modules, should we every decide to publish them).
I believe our current jitpack config doesn't actually work correctly
because we only publish artifacts from the main package, but not core.

You can see this in practice when looking at:
https://jitpack.io/com/github/MobilityData/gtfs-validator/3.0.1/gtfs-validator-3.0.1.pom

Notice how it has a dependency on the `core` module but we don't
actually publish it anywhere.  If you actually attempt to use our
project as a jitpack dependency, it will fail.

The change was to also publish the core module and to specify more
natural artifact names.

longer needed now that project version is determined within Gradle
directly.

Also fixup references to shadow jars, since they no longer include
the versionTag in the filename (also _cli => -cli).

We can't update this code until the PR actually goes in on the master
branch.

…flicts.

I also cleaned up some other variables from the docker config that don't seem to be used.

…previous commit.

…now that PR MobilityData#1147 has been committed.