Improve Docker container initialization

[pavelhoral]

This PR overhauls docker image structure and initialization with the following changes:

• better environment variable conventions (additional options and sensible defaults)
• custom entrypoint with server automatic initialization and upgrade
• global ssoadm wrapper script capable of lazy initialization
• sample configuration to get the server up and running with a one-liner

[pavelhoral]

Feedback from @RoBobik and @fyrbach :

• there is no mechanism how to provide custom keystores as Wren:AM automatically updates the keystore during the setup
  • Wren:AM will not initialize when there is already a keystore present (i.e. mounting it in advance does not work)
    • TASK check if we can make the initialization to use existing keystore
  • keystore is stored in the instance config directory, so it will break the "already configured" check in the entrypoint/init
• there are no checks for a running config/user store when they are external (i.e. embedded LDAP not used)
  • the default entrypoint might not need to address this; waiting for external services can be handled outside of the init script
  • not sure if the user store (data store) is even necessary for the initial setup
    • TASK check if we can initialize new platform without data store (or at least if we can ignore the error as the check is being made quite late in the initialization process)
• we need to allow specifying custom JVM options for SSOADM
  • this might be necessary to setup site-server mapping (com.iplanet.am.naming.map.site.to.server) and other custom stuff
  • ideally ssoadm should work with WRENAM_SSOADM_OPTS environment property
• the proposed initialization calls only a single ssoadm config.batch file, might make sense to load all .batch files from the init directory (similar to what PostgreSQL is doing)
  • this might be a potential improvement later on... config.batch batch can import other batch files in the current approach
• the question of interpolating variables in initialization / configuration / upgrade files
  • current approach in this PR expects that the initialization, configuration and upgrade files are provided by the user;
  • a different approach can be for the entrypoint to generate initialization / upgrade properties based on environment
  • probably even better approach would be to support property interpolation so that user can provide files and have selected values to be inherited from the environment
    • this means that the current approach is a good starting point and there is a potential product improvement

[pavelhoral]

There is also one additional talking point: Do we want to have environment variables prefixed with WRENAM_? I like it that way, but for example with Wren:DS we have decided to leave the prefix out.