Stamp final artifacts

Merge Implementation-Version into the final artifacts. This has two
advantages: for one, it can be later tracked down, from what release
this artifact was consumed; for another, in case a release was produced
without touching any source files but only bumping some dependencies,
that are not shaded in the final artifacts and thus do not contribute
to the SHA1 update of the final artifacts, the SHA1 would still change,
because of the changed content of the META-INF/MANIFEST.MF file. For
example building from this commit will produce the following manifest
content:

  $ bazel build java/com/google/gitiles/blame/cache:cache-stamped
  bazel-genfiles/java/com/google/gitiles/blame/cache/cache-stamped.jar

Unzipping the content of the cache-stamped.jar produces the following
implementation version:

  $ cat META-INF/MANIFEST.MF  | grep -i Impl
  Implementation-Version: v0.2-3-7-g9af1a70

Change-Id: Idb6e7c635ae254188e1ee6592e0e0502c7c338a6
diff --git a/tools/workspace-status.sh b/tools/workspace-status.sh
new file mode 100755
index 0000000..9cc40e9
--- /dev/null
+++ b/tools/workspace-status.sh
@@ -0,0 +1,17 @@
+#!/usr/bin/env bash
+
+# This script will be run by bazel when the build process starts to
+# generate key-value information that represents the status of the
+# workspace. The output should be like
+#
+# KEY1 VALUE1
+# KEY2 VALUE2
+#
+# If the script exits with non-zero code, it's considered as a failure
+# and the output will be discarded.
+
+function rev() {
+  cd $1; git describe --always --match "v[0-9].*" --dirty
+}
+
+echo STABLE_BUILD_GITILES_LABEL $(rev .)