Port build system to work with git

[Work item, just after the migration to git]: Port the cmake files (and the documentation) to use git commands instead of bzr. There are mentions of bzr in the following files:

CMakeLists.txt
packaging/win32/inkscape.nsi
packaging/release-sign-tarballs
doc/HACKING.txt
CMakeScripts/cmake_consistency_check.py
CMakeScripts/inkscape-version.cmake

> Just as a remark, there will be bugs linked to the transition from bzr
> to git itself: some build parts are linked to "bzr revno" for instance,
> so some cmake code will have to be fixed just after the code migration,
> and we'll also have to decide what to put in the about screen instead of
> the revno. Probably the best option might be the git commit hash and/or
> datetime if it's easily extractable from git.
>
> "Inkscape 0.92+devel (2017-01-18 17:38:31)" might be more readable than
> "Inkscape 0.92+devel f0e47570d3776c373066cc61595b1ba14fa9b366"

Another option might be:

"Inkscape 0.92+devel (2017-01-18 f0e47570)"

The first 8 chars of the SHA are usually always adequate to uniquely
identify the commit, and will be more manageable than the full SHA in
this case.

I do think showing the (partial) SHA is what we want, as the purpose of
showing the revno is to assist in identifying where a regression
occurred, and since a number of git commands work with SHAs so listing
it here will eliminate an extra step that bug triagers would need to do
anyway.

Showing the date is handy too since it'll communicate to users the
relative age of the build (which SHA's don't communicate in the way that
bzr's revno's do.) We have a few different options for what date to
show: The commit date of the patch, the author date of the patch, and
the build date. Guessing the commit date would be most logical here but
I'm not actually sure.

--------

Ack. A nice way of getting such a version string is

git describe --tags --dirty

which will tell the last tag, whether there are changes to the checkout (the
--dirty), the short hash of the last commit and also the number of commits
since the tag. For darktable that looks like this:

release-2.3.0-266-gfefb0204e-dirty

It's not too hard to clean up the tag name (remove "release-") and add the
commit date.