build: Allow backend libraries to have separate LT versions from libfolks.so

With the addition of the dummy backend, backend libraries (such as
libfolks-dummy.so) no longer necessarily have the same stability guarantees
as the core of libfolks. Consequently, they must have separate LT versions.

These versions will be incremented in-line with the core LT version, but
may also be incremented separately. They don’t affect whether libfolks will
load a given backend module (that’s predicated on the core LT current
version); merely whether client code needs to be re-linked against a given
backend library due to an ABI-incompatible change in its backend-specific
API.

https://bugzilla.gnome.org/show_bug.cgi?id=711544
build: Minor build simplification

No need to create a new directory variable; just use lib_LTLIBRARIES
directly.

https://bugzilla.gnome.org/show_bug.cgi?id=711544
build: Factor common backends/*/lib makefilery into backend-library.mk

This simplifies and standardises the build process for the installed
backend libraries (libfolks-eds.so and friends).

https://bugzilla.gnome.org/show_bug.cgi?id=711544
build: Allow backend libraries to have individual API versions

The API version is included in the GIR file name, and only changes when
API is broken or removed. If new backends, such as the dummy backend,
are to have unstable APIs, having individual versions for each backend
library is necessary to allow backend API breaks without breaking the
whole of the folks API.

The API version has not been added to the VAPI file name, though it
should, because that would be a backwards-incompatible change. It can be
added when folks next breaks API compatibility.

https://bugzilla.gnome.org/show_bug.cgi?id=711544
build: Update git.mk to fix valac-generated C header file ignores

Update to the latest git.mk from master.

https://bugzilla.gnome.org/show_bug.cgi?id=711544
build: Ensure the TpLowlevel GIR and typelib are cleaned properly

https://bugzilla.gnome.org/show_bug.cgi?id=711544