Re-design how Fluentd should be deployed as a Daemonset

Current structure of this suggested way to deploy Fluentd as a daemonset is generating some complications to maintain different based distro, plugins and different setups.

Taking in count @chancez suggestions, I think this could work as:

- One debian base image:
- Deprecate Alpine because of: cannot work with systemd, hard to maintain with Jemalloc enabled (required to reduce memory usage because of high glibc memory fragmentation).
- Debian image by Google (gcr.io/google-containers/debian-base-amd64:0.1) is really secure,
- Use ConfigMaps instead of configuration files inside the images
- Similar documentation to the one existing by [CoreOS/Tectonic: Logging](https://coreos.com/tectonic/docs/latest/admin/logging.html)

Please share your thoughts and ideas.

Review the current Fluentd DaemonSet deployment, image variants, and configuration-file setup, then compare the proposed ConfigMaps and Debian-based approach with the linked CoreOS/Tectonic logging documentation. The issue does not name files or tests; the work is not complete until the deployment design and its maintenance implications are agreed.

Written by the indexing model from the issue text.