Moxie's deploy task updates the `artifacts.json` file in the Maven
repository. But it does rewrite the whole file, not just add the
newly deployed artifacts. Which causes the "last updated" dates for
all artifacts in the repository to be rewritten.
In our case, where the repository is a Git repo, if the Git repo is a
fresh checkout, that resets all the dates to the checkout date.
Therefore we adjust the `artifacts.json` file to only keep the
update for the newly deployed artifacts, removing the other updates
for the dates with some awk magic.

Refactor the creation of the release process script, from
`release.template` into a `macrodef`.
Add a new target `releaseScript`, so that the release script can be
created after the `tagRelease` target was run.
This is helpful if the `tagRelease` target is run by a different,
earlier process than the actual release creation process.

Set the ignored branches pattern to `release*` for the normal ci workflow.

If requested, by setting a file name in the `versionInfo`
property, store release version and tag in a file, for
other scripts and programs to pick up.

Use the same templates as in `buildSite` to generate the change log
in the built-in documentation.

Moxie does have these defined by default, but with transport HTTP.
Since January 2020, Maven Central only accepts HTTPS, no HTTP
anymore. So we add them here explicitly, with `https://`.
We add it to the `build.moxie` file, instead of keeping it in a
local `settings.moxie`, so that a CI server can immediately use it.

Since Google Plus doesn't exist any more...

Add pages for `fail2ban` and GFS to the `generateDocs` target, so that
they also show up in the documentation on GO etc.
Also adjust the links to issues and commits.

Add the replacement of the download base URL.

Google Plus is gone, so linking to it makes no sense anymore.

Add property `release.tag` to keep a generally available property.
The `project.tag` was getting used in many places, so I need a global
definition for it. The property `project.tag`, defined in the target
`tagRelease` could not be reused, since when that target runs, the
version is still a SNAPSHOT version. (And properties don't get
re-assigned.) So instead a new property `release.tag` is defined,
just like `release.name`, which can be only used sensible in a
release stage, i.e. after `tagRelease` ran.

The site was generated, but updating the gh-pages branch was included
in the `publishSite` target. So a new target is added and called,
`updateSite`.

The major change is switching from `publishBinaries`, which still
exists and uploads to Bintray, to `releaseBinaries`, which creates
a draft release on GitHub and uploads the binaries.

Another change is some reordering. Now first the binaries are
uploaded, the maven artifacts pubished and the tag and site pages
pushed. Then the GitHub release is made public.
Only after that is the minor version bumped and pushed.

The whole script could use some error checking and stoping when
things go wrong, instead of blindly continuing.

A minor change, and temporary, is that we need and check for Ant 1.9,
as we still build with Java 7.

Add Ant tasks and macros to deploy binaries to GitHub,
using GitHub's releases.

Adds an Awk script to extract GH flavoured markdown release notes
from the release.moxie file.

Adds `ok.sh` to the repository so that it is readily available.
This is a Bourne shell GitHub API client, used to create a release
on GitHub and upload the binaries.

Now we can also build on GitHub

ci ignore

Add a job to run a build with Java 7.
The job currently only runs on Linux.
In order to run on Java 7, an old Ant version is downloaded and
installed. We use moxie+ant for this, so we build with moxie.

Currently that is Ubuntu 18.04 and Windows Server 2019.
https://help.github.com/en/actions/automating-your-workflow-with-github-actions/virtual-environments-for-github-hosted-runners

We cannot build with Ant on GitHub since the provided Ant
version does not run on Java 7.

I actually don't know if it is needed for the manager and fedclient,
but right now I'm going with better safe than sorry.

Adjust the version of JaCoCo down to 0.8.4 and the version
of parboiled-java up to 1.3.1. They need to match because both
use ASM. This combination has the same dependency on ASM: 7.1.

And it seems to work, at least the docs get generated and the
`moxie test` doesn't fail building the report anymore.

With the feature of passwords getting automatically
upgraded to a hashed version, the default `admin`
password in the test-users file will get stored
as MD5 hashed during test execution. Commit this
change, so that the file isn't always showing up
as changed.

Running `moxie test` will crash under Java 11 with JaCoCo 0.7.8.

Two fixes: broken links to docs and preferred language selection

Due to a wrong comparison, when loading the preferred locale in the
user preferences page, in cases like `zh_CN` or `de_DE` the wrong
locale would be chosen.

As with too many things, the code is duplicated on the `UserPage`
and the `EditUserPage`. And they differ. So extract the choosing of
the preferred language for display into a method in the (more up-to-date)
`UserPage` and call that from the `EditUserPage`.

If, for example, an external site links to a docs page or a specific
doc page, and the branch that link points to is no longer existing,
an internal error happens due to a NPE.

The NPE is guarded against and a No Docs page is returned.

Renames `static final` variables according to convention to be in all
upper case. That makes it easier to see that in an `equals` comparison
the final variable should come first as it will not trigger a NPE.

Also strip parameters from the URL when extracting the repository
name from it. Parameters can not be part of a repository name, and
this way an empty repository name can be detected.

Fixes #1092