Changes how the kernel version/revision gets generated

The problem:
Kernel version is gotten from 'git describe' which looks at the most
recent tag reachable from HEAD. If HEAD _is_ that commit then it'll be a
clean e.g. '1.9.RC2' version, otherwise it'll add
'-<nr-of-commits-ahead>-<short-commit-hash>'. They way the branches are
set up currently yields that tags made in master will be merged into 2.0.
Therefore the latest tag (i.e. release) of either 1.9 or 2.0 will be
chosen by 'git describe' when describing 2.0.

The solution proposed here:
Don't use 'git describe' since it doesn't suite our branch strategy.
Or rather, still get the 'dirty' part from it (i.e. whether there are
local changes or not when doing the build).
Instead use the version found in the pom, along with current branch and
commit hash (if the version is a SNAPSHOT version). Examples:

  2.0.0-M02
  2.0-SNAPSHOT-2.0-58f0e945df96d9a71184e4a0bbcdaf4e42271770-dirty
  2.0-SNAPSHOT-mylocalbranch-58f0e945df96d9a71184e4a0bbcdaf4e42271770

Caveat for not showing <branch>-<commit-hash> if not a SNAPSHOT is of
course that the version can be faked, but that goes for the previous
solution as well of course where one could alter tags before building.