track gwc cache hits

[rmarianski]

@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.

[jdeolive]

Looks good to me. Logic looks sounds.