Use git description as the tinc version.

Instead of using the hardcoded version number in configure.ac, this
makes tinc use the live version reported by "git describe",
queried on-the-fly during the build process and regenerated for every
build.

This makes tinc version output more useful, as tinc will now display the
number of commits since the last tag as well as the commit the binary is
built from, following the format described in git-describe(1).

Here's an example of tincd --version output:

  tinc version release-1.1pre10-48-gc149315 (built Jun 29 2014 15:21:10, protocol 17.3)

When building directly from a release tag, this would like the following:

  tinc version release-1.1pre10 (built Jun 29 2014 15:21:10, protocol 17.3)

(Note that the format is slightly different - because of the way the
tags are named, it says "release-1.1pre10" instead of just "1.1pre10")

If git describe fails (for example when building from a release
tarball), the build automatically falls back to the autoconf-provided
VERSION macro (i.e. the old behavior).
Use git describe to populate autoconf's VERSION.

This uses the output of "git describe" directly in configure.ac to
determine the version number to use, instead of hardcoding it.

With this final change, current version information is completely
removed from the codebase itself, and is always fetched on-the-fly
from git as the single source of truth.

On release, an automated process ensures that the current commit is
tagged, regenerates the configure script to make sure it has the final
version information from git (this is important as it is then used in,
the tinc version output code itself if building from a release tarball
because git is unavailable then), and the normal autoconf check makes
sure that the tag appears in NEWS.

Note that the prompt to edit NEWS is removed, because the new process
requires the release to be tagged beforehand, and NEWS must be committed
before the tag is applied.