Change SpringSessionGemFireConfigurer behavior to only apply configuration for the callback methods the user has actually implemented

[jxblum]

Currently, the configuration applied by the SpringSessionGemFireConfigurer is all or nothing (as described in the docs), even if the user only implements a single callback method affecting the configuration of SSDG (e.g. getClientRegionShortcut()) via a SpringSessionGemFireConfigurer bean instance.

This makes the use of the SpringSessionGemFireConfigurer less flexible when only a single attribute/property needs custom, conditional logic that is better suited in code then as an annotation attribute, or as expressed in a property, especially since a user could be using a combination of Annotation attributes or the well-known SSDG properties (e.g. spring.session.data.gemfire.cache.client.region.shortcut as documented in the @EnableGemFireHttpSession annotation, clientRegionShortcut attribute) in Spring Boot's application.properties, in addition to the Configurer when configuring SSDG.

This issue intends to change the behavior to be additive/overriding, with precedence. The precedence will be...

1. SpringSessionGemFireConfigurer (for only the callback methods defined in the SpringSessionGemFireConfigurer interface that the developer actually "implemented").
2. Well-known SSDG properties (e.g. spring.session.data.gemfire.expiration.max-inactiver-interval-seconds)
3. And finally, the @EnableGemFireHttpSession attributes themselves.

In other words, if all 3 configuration approaches are used for a particular attribute, e.g. session expiration timeouts, then SpringSessionGemFireConfigurer.getMaxInactiveIntervalInSeconds() followed by the spring.session.data.gemfire.session.expiration.max-inactive-interval-seconds property followed by the @EnableGemFireHttpSession.maxInactiveIntervalInSeconds attribute will be evaluated, in that order until 1 the configuration provided by that approach.

[jxblum]

This will also be included/back-ported to the SSDG 2.0.7.RELEASE.