Fixed issues with event processing in cluster nodes.

- Repeated failed to process events were logged because the head of
the event queue wasn't being removed. Instead, the queue was traversed
through its iterator and the Iterator.remove() were being called only
upon a success. Hence furter processing tasks got the same event that
kept failing.

- It was possible that a REMOVE event was queued while its corresponding
ADD event wasn't yet processed, leading to unnecessary logging of a failed
ADD event, since the object was already deleted from the catalog. Added a
check to verify whether a REMOVE event for the same object is scheduled
before complaining when processing a ADD/CHANGE event whose object is not
found in the catalog.

- The Hazelcast synchronizer was not aware of application lifecycle, so
when a node joined the cluster it starts trying to process events before
the application is fully loaded, and keeps processing events when the
application is shuttting down. Added a 'started' state to HzSynchronizer
that's set to true once the app is ready and to false when it's shutting down,
preventing the attempt to process events when the catalog is in a state of
flux, which is specially problematic with jdbcconfig. This avoids
ConcurrentModificationExceptions to be thrown while the synchronizer tries
to notify the catalog listeners which are being added/removed, and hence
may try to notify a catalog listener that's no longer valid.

- Homogeinized the log messages to contain the current and origin node ids
and a consistent representation of the events.

- Guarded the traversal of catalog listeners using a local copy since the
GeoSever's CatalogImpl.listeners list is not thread safe.