Allow configuring query caches

Updates `HazelcastQueryResultsRegion` to pass the `HazelcastInstance` through to the `LocalRegionCache`. To retain the existing behavior of not using a `MessageListener`+`ITopic` for invalidation, added a new constructor to `LocalRegionCache`.

In summary:

- Added a new constructor to LocalRegionCache to allow explicit control over whether an ITopic MessageListener should be registered
- Fixed a subtle bug in LocalRegionCache.cleanup() that prevented multiple entries with the same timestamp from being cleaned up
    - Using a TreeSet meant only a single entry at any given timestamp could be considered as a candidate for eviction; subsequent entries were "protected" because they weren't added to the TreeSet
- Updated HazelcastQueryResultsRegion to use the new constructor so that the HazelcastInstance can be passed on (allow query caches to inherit their MapConfigs) without registering a MessageListener
- Added unit tests to verify both LocalRegionCache constructors
- Added unit test to verify HazelcastQueryResultsRegion creates LocalRegionCaches which honor their configurations
This was something I ran into while writing my unit test. All of my entries ended up with the same timestamp, so only a single entry was added to the `TreeSet`. That meant where I expected `cleanup()` to remove 60 elements it only removed one.

While that's certainly an almost impossible scenario to achieve in a real application, having more than one entry with the same timestamp is certainly not impossible. Using a `List` here ensures correct eviction behavior, ensuring _all_ entries at older timestamps are evicted before newer entries. Since that seems more correct I chose to include this change in this pull request.