Add stub instance configuration which just establishes a way to have
several software types(*), pass all needed info from software to
instance, organizes base directory and establishes log rotation base for
upcoming services.

Log rotation is done with the help of cron periodicallly calling
logrotate. The rotation is done in "copytruncate" mode - i.e. log file
is not moved away and signal sent for service to reopen it, but instead
log content is just copied to outside and there is no need for a service
to reopen it's log file.

The reason it is done this way, is that there is a chance of not
handling such "reopen-log-file" callbacks correctly on a service side,
and so the net is full of crashing reports, e.g. like this:

    http://serverfault.com/questions/627521/why-is-logrotate-causing-apache-to-seg-fault-each-time

That's why we take a safer approach instead, even if "copytruncate" mode
is risking to loose several log entries(**) on rotation.

NOTE services will organize log rotation with just

    [logrotate-entry-<service>]
    <= logrotate-entry
    log     = path/to/log/files/*.log

For this to work some "!py!" magic (our way to serialize object into
executable python and process it in buildout recipes) is used to process
section names.

The approach trick is also used for cron, e.g. logrotate registers to
cron this way:

    [cron-entry-logrotate]
    <= cron-entry
    time    = daily
    command = ${logrotate:wrapper}

NOTE2 instance md5 are not fixed yet - we'll fix them after applying all
    patches in gitlab series.

(*) for now there is only 1 - "gitlab", but we'll need to have "-export"
    and "-import" for resiliency in the future.

(**) ideally such things should be done with logfs - a filesystem
    specializeing in logging - for client services it will look like as
    they just continue to write to log file, and on log service side, the
    rotation can happen, all transparent to client service.

/cc @kazuhiko, @jerome