Add build information to jars

[devinrsmith]

For benchmarking and other provenance use cases, it would be useful to have more build information as part of the jars.

The most useful pieces of information would probably be:

• git commit hash (-dirty)
• Is this a release build?
• Build date / timestamp (this may come into conflict with development workflows which may favor cacheability, so ostensibly may only be desired on release builds)
• Other build environment details

The most canonical place to add this information would be in the jar manifest META-INF/MANIFEST.MF: https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#jar-manifest.

Here is an example of our current manifest:

Manifest-Version: 1.0
Implementation-Title: Deephaven
Implementation-Version: 0.23.0
Provider: gradle

Note: regardless of adding more build information, we may want to change Implementation-Title to actually be the archive base name instead of "Deephaven".

We could add build information to a separate file in the jar, but unless there is a strong compelling reason why we shouldn't add it to the manifest, the manifest is likely the best choice.

As an added bonus, this would give us an opportunity to add information that automating tooling likes to look for (license, PURL info, ...). We recently did this for deephaven/deephaven-csv#93:

Manifest-Version: 1.0
Specification-Title: deephaven-csv
Specification-Version: 0.10.0
Specification-Vendor: Deephaven Data Labs
Implementation-Title: deephaven-csv
Implementation-Version: 0.10.0
Implementation-Vendor: Deephaven Data Labs
Implementation-Vendor-Id: io.deephaven
Implementation-URL: https://github.com/deephaven/deephaven-csv
Bundle-License: https://www.apache.org/licenses/LICENSE-2.0.txt

[stanbrub]

A build number would be beneficial as well. During feature development, the version gets bumped but the only thing distinguishing one build from another is timestamp.

If and when Benchmark is running 24 hours a day, or in parallel, or we need to re-run against a past build, we need a reliable identifier that is unique for every set of bits. It also must be sortable from newest to oldest. Maybe a time-based UUID?