XD-891 Runtime containes/modules info

- Added store option for container to persist container/module info
 - The container and module event listeners no longer *transport* specific
   Instead, based on the store used:
     - the container start/stop events update at ContainerRepository
     - the modules deploy/undeploy events update at ModulesRepository (where
       the modules of mapped under the groupName of the deployment request)
       and, at ContainerModulesRepository (where the modules are mapped by
       the container that deployes the module)
 - Removed the transport specific event listeners from Redis & Rabbit transport
   based container configs
- Added REST controllers ContainersController & RuntimeModulesController
  to interact with containers/modules repo
 - Added 'runtime/containers' to list containers
 - Added 'runtime/containers/{containerId}/modules' to list the
   runtime modules on a given container
 - Added 'runtime/modules' to list all the runtime modules
- Added REST client/Shell commands implementation
 - Added Shell commands:
     'runtime containers' to list containers
     'runtime modules' to list modules
     'runtime modules --containerId <id>' to list modules by container
     'container list' to list containers (this implementation at ContainerCommands
       can be used for future container specific commands)
XD-891 Add tests

- Added tests for Container & Runtime shell commands
- Added tests for Containers & RuntimeModules REST controllers
- Fixed review comments
 - Made hashOperations visibility to be private and added accessor
 - Added constant declarations for ModuleEntity index fields
XD-891 Remove ContainerOperations

- Removed ContainerOperations and its implementation
 - Moved the listContainers into runtimeOperations
- Removed ContainerCommands and its tests
- Fixed review comments
XD-891 Remove system.out.println
XD-891 Fix review comments
XD-891 Fix listRuntimeModulesByContainerId

- Fixed the listRuntimeModulesByContainer to return Page resources
  instead of List.
- Also moved this method to RuntimeModulesController
XD-940 Fix Splunk SI Transitive Dependency

For some reason gradle pulled a transitive SI version into
launch classpaths from the SI splunk extension.

Normal gradle builds worked fine; as were the 'Referenced Libraries'
in STS.

Explicitly set the SI version for the splunk extension.
XD-926 Update to SPR 4.0.0.M3

Issues:

- GenericApplicationContext needs refresh()
- GenericApplicationContext doesn't allow getBean after destroy
     the ModuleDeployer tried to unbind the channels after destroying the context
- Problem with @Autowire and @Qualifier when bean in parent context

Resolution:

- Add refresh() to test that needs it
- move module.close() until after unbind
- Under investigation; work around is to not use a qualifier but name the parameter with the bean name

Also:

- Add qualifier to SimpleModule.toString() to enable debugging when the same module is deployed multiple times in tests
INT-926 Polishing

- Stop the module before unbinding it
- Destroy the module's context after unbinding it

Previously, the context was stopped and destroyed in module.stop()
which caused the unbind to fail with SPR40.