ISPN-374 Initial Hot Rod remote events support

* Created, modified and removed events and their expectations with each of the Hot Rod operations.
* Filtered events with optional binary parameters on registration.
* Custom events with optional binary parameters on registration.
* Testing event consumption for distributed and replicated caches with filtering, custom events...etc.
* Initial Java Hot Rod client implementation with support to add and remove listeners, including passing converter and filter factories and support for parameters.
* Server configuration gets a Marshaller configured to be able to unmarshall binary parameters for filter/converter and pass them to the callbacks unserialized.
* This marshaller also used to enable fully typed converter/filter implementations rather than working on binary payloads.

Consider this PR to be 90% complete with the following work still required:
* For server integration, there needs to be a way to deploy these filter/converter factories and their filter/converter instances into the server. This ([ISPN-3950](https://issues.jboss.org/browse/ISPN-3950)), along with tests that verify that remote events work in server are still. UPDATE: I've started investigating this and need to check with @tristantarrant, but if you want to deploy a `KeyValueFilterFactory` in the server, the interface will need to provide the name of the filter factory, i.e. via a `getName` implementation? Or via the Hot Rod server endpoint configuration? @tristantarrant  thoughts?
* The Hot Rod server configuration now has a marshaller configured which is used to enable typed filter/converter parameter handling, and in order to enable typed filter/converter callbacks. Note that this is separate from the cache marshaller, and separate from the compatibility marshaller, both of which, have different objectives. For example, you don't want to force compatibility to be enabled to be able to have typed converter/filters. This type conversion has been implementing using BinaryFilter/BinaryConverter classes which unmarshall the key/values and pass them to the filter/converter instances that the user has configured. There's a problem with this when running in a cluster. Part of the cluster listener logic involves serializing these filter/converter instances and sending them to other nodes. However, these Binary* classes require the marshaller to do their job, which is not serializable. However, the marshaller could be plugged to the Binary* classes if there was some kind of callback or something in each node that gets these classes replicated to, and it can initialise it properly. I suspect some users might have similar requirements with their filter/converter instances. I briefly discussed this with @wburns yesterday, but we did not conclude on a particular solution for it. So, for the moment, the marshaller used by these classes is hardcoded.
* ~~Also missing are tests that verify that events are received for existing contents in the cache when the client adds the listener. I implemented a test or two, but they're disabled pending integration of @wburns' distributed entry iterator PR (#2513).~~ <- completed
* ~~Implementing retrieving the list of listeners.~~
* ~~Implement removing listeners on disconnect.~~
* ~~Update documentation with the remote event stuff, as well as other Hot Rod 2.0 improvements I've worked on, particularly in the protocol side.~~ <-- Documentation added in separate commit. Missing documentation is related to handling of event consumption when the cache already contains data, or when there's a failover of the listener. 
Actually I just thought about this, but do we want the current state to be optional for a client listener?