Further distinguish single host deployments from docker compose deployments

We already inject a different base path in release builds of ocis. See release.mk:
```
# docker specific packaging flags
DOCKER_LDFLAGS += -X "$(OCIS_REPO)/ocis-pkg/config/defaults.BaseDataPathType=path" -X "$(OCIS_REPO)/ocis-pkg/config/defaults.BaseDataPathValue=/var/lib/ocis"
DOCKER_LDFLAGS += -X "$(OCIS_REPO)/ocis-pkg/config/defaults.BaseConfigPathType=path" -X "$(OCIS_REPO)/ocis-pkg/config/defaults.BaseConfigPathValue=/etc/ocis"
```

There was a question about enabling TLS or disabling it for single host deployments, as certificate rotation is not yet covered.

The goal for ocis releases is to be secure by default. We use `ocis init` to roll random keys and an admin password. While I think that makes sense I also see the use case for single host deployments that might want to use unix sockets instead of TLS encrypted tcp ports. We would trade certificate rotation for unix socket permissions which can be accessed used when an attacker can become the user that has access to them. It depends on the tradeoffs and the threat model.

TLS certificate rotation is just one aspect, there are others like which cache to use (in memory vs redis/etcd/...) which are different in single vs multi host deployments.

Since we are using docker compose or kubernetes to deploy in multi host scenarios I think it would make sense to compile in defaults for a single host deployment and use docker compose to:
- enable TLS
- switch from unix sockets to ports
- use redis instead of in memory caches
- start redundant services

Other aspects?