Switch to Release Service driven versioning

In preparation for move to KDE Release service at begin of November:

With the switch to Release Service and its automation, the automatic version bumping available is happening via the RELEASE_SERVICE_* variables in the toplevel CMakeLists.txt file. They will be bumped by the release handling scripts automatically.

There are two variants done by projects covered by Release service for having the own software release version being derived:

• use the full Release Service version number ("yy.mm.patch" -> "20.12.0" would be upcoming release)
• use some base feature-set-centric version and use Release Service version numbers for patchlevel part ("x.y.yymmpatch" -> 1.8.20120")

I propose to use the latter for now: in case someone moves Konversation back to custom releases, the version number can follow the current version numbering without a break in sequence (which confuses package upgrades and users). And bumping the 1.7 to 1.8, to reflect the few new features.

The generated src/version.h holds this with the current variable (and yes, the KONVI_VERSION number is bogus, we are only interested in the string KONVI_VERSION_STRING):

// This file was generated by ecm_setup_version(): DO NOT EDIT!

#ifndef KONVI_VERSION_H
#define KONVI_VERSION_H

#define KONVI_VERSION_STRING "1.8.201170"
#define KONVI_VERSION_MAJOR 1
#define KONVI_VERSION_MINOR 8
#define KONVI_VERSION_PATCH 201170
#define KONVI_VERSION ((1<<16)|(8<<8)|(201170))

#endif

This loses the commit/build feature, though people had been slacking to keep it updated the last years, so its loss should not be that grave. And ideally something like a build stamp should be generated automatically by the build system for all apps. IIRC Krita and some other apps have this, time to turn it into some ECM macros and make it available to everyone.

@psn @hein @argonel @buschinski