Fix CacheUpdateAware mechanism in cluster.services-implementation

Fix CacheUpdateAware mechanism in cluster.services-implementation
bundle

- Add the logic for clustering.services_implementation bundle to track
all the ICacheUpdateAware services and to relate them to a container
or a global context. Make sure to be able to handle the service
registering and unregistering case. In case of
registration/deregistration of an ICacheUpdateAware check for the
"cacheNames" property and then use it for learning for what caches the
updates will be generated. Also make sure in phase of registration if
there is an attempt to override a registration for an existing cache
to avoid it and to raise an error message.
- Given the LDAP filter that allows to track for the global
ICacheUpdateAware services match also the per-container ones, make
sure that ClusterGlobalManager filter them out before reaching the
ClusterManagerCommon, in fact that would prevent to handle seamlessly
the case of cache name being the same in global context as well
per-container.
- Removed stale OSGi declarative service file in
clustering.services-implementation bundle.
- Created extensive integration test case for clustering.services to
make sure the logic is correct and automatically tested.
- Added two new ServiceHelper methods that allow to register and OSGi
service and to get back a ServiceRegistration, extremely useful in
integration tests to test difference between when a service is present
and when it's gone.
- Added logback.xml for the unit tests of
clustering.services-implementation bundle to avoid to print out infos
while executing the unit test that would be useless
- Modified ClusteringServicesIT to use the versionAsInProject on all
the configured bundles, so to avoid too much manual sync process
between the versions in the POM and in the configuration

Change-Id: Id1ae2e22e2896df686a377fd3ae9f232f3545bca
Signed-off-by: Giovanni Meo <gmeo@cisco.com>