HotRod-based session manager should use max-active-sessions to configure L1 per remote cache

Currently, the hotrod-based session manager uses the l1 configuration of the associated remote-cache-container to determine the number of entries to retain in memory. This has the following drawbacks:

• any configured max-active-sessions (from jboss-web.xml) is ignored
• the remote cache for each deployment of a given remote-cache-container will use the same configuration
• the value does not reflect the number of sessions, but, rather, the number of cache entries, which requires the user to be familiar with how sessions are mapped to the cache, which itself depends on the configured granularity.

In order to align this behavior with the other session manager implementations, L1 should be configured per remote cache based on the value specified by max-active-sessions. This requires several changes:

• Add the ability to override the near cache implementation per remote cache
• Create a custom NearCache<K, V> implementation configured with a custom Caffeine cache configured with a custom weigher, similar to how max-active-session is implemented via a custom data container.
• Add listener mechanism to support cascading of L1 invalidations to dependent entries