track gwc cache hits

@jdeolive @tschaub @jmarin 

Any chance any of you can review this? It was a little bit more invasive, and I wanted to have a quick sanity check.

Quick synopsis:

* new console specific ows callback created to track gwc cache hits
* maintaining a concurrent hash map to correlate monitor-core request data objects and console specific data objects
  - monitor-console needed a place to store additional data during the request lifecycle (an alternative could be to have the monitor-core's RequestData grow the ability to hang other data generically off it)
  - RequestData::id is used to establish the link. Hopefully this can be counted on to be unique. In my testing it was.
  - I'm manually removing entries from this map after done to prevent memory leaks. Maybe a weak hash map can be used instead as a better guard? I don't understand weakhashmaps well enough to be able to say definitively here.
* if we have console specific data (currently only if it was an ows request) then I include whether it was a cache hit or not at the root of the json in the serializer. On the receiving end this means that it's either present as a boolean, or not in the document at all.
* I attempted to factor out the logic of determining whether a request was a hit or not so it wasn't directly in the callback. My hope was that it, or something like it could be useful in other contexts.