Cluster CacheProvider for jdbcconfig, and make cluster config event dispatch wait for acks.

One of the issues with outdated info (e.g. FeatureTypeInfo attributes) when querying
a cluster member is that the jdbcconfig catalog's ConfigDatabase uses a local cache
of CatalogInfo objects by default. Hopefully it uses a plugable mechanism to find a
CacheProvider. This patch introduces a cluster wide distributed cache based on a
HazelCast distributed Map so that all cluster members use the same cache.
The number of entries in the cache is unbounded but they expire and are evicted after
5 minutes of being last accessed.

The other issue is that a client modifying a CatalogInfo object through the REST API
to one cluster member, and immediately after querying (say, through WFS or REST) that
object to another cluster member, may see outdated info due to the HazelCast topic message
not having reached the second member or not having been processed yet (which forces
the geoserver catalog to clear any cached data especially in the ResourcePool).
This patch introduces an ack callback message so that the cluster member issuing the
change event can wait up to a reasonable period of time for other members to signal back
that they received and processed the event.