CDK-604: Added commands to generate logging and Flume configs

* The Flume configuration defaults to an AvroSource listening on 0.0.0.0:41415
* The Flume configuration defaults to a file channel
* The log4j configuration defaults to writing to port 41415, but requires the hostname
* The log4j configuration requires a package or class name to log to Flume, or a
  switch of --log-all to configure the rootLogger.
* Besides the unit tests, I ran some manual tests on a cluster by completing the
  logging example, but using the tool derived configs rather than the ones that
  shipped with the example.
> If we provide default values, then the user is much more likely to miss them even if we try to prompt them with an edit location in the generated file.

I agree. What I intended was to have the property name correctly created, but in a comment line like this:
```
# A list of directories where Flume will persist records that are waiting to be processed by the sink.
# You can use multiple directories on different physical disks to increase throughput.
# tire1.channels.kite-dataset-channel.dataDirs = /var/flume/data/p1, /var/flume/data/p2
```

> I don't think it's a safe assumption that users will edit the configuration files prior to attempting to use them.

I think you have a good point here, but I think they are even less likely to look up the meaning of options they don't understand. We will produce a "working" configuration either way, so they have no reason to look up the options available to them.

I also think once the configuration is deployed, there's a good chance that even if they did look up the options, they will want to change it and the easiest way to do that will be by editing it in-place rather than regenerating it with Kite. Editing the configuration at that point is the easiest path to a fix, rather than going back, digging up the command used to generate the first config, adding an option (and looking up its meaning) and copying that new config into CM. Even if we have good docs, users will very likely google their problem and get pointed to a Flume-level fix. From there, they either edit the config by hand or do more work to find out how to make Kite regen their config with that option, then redeploy it. I think we have to count on users editing these files so our goal should be to make it easy for them to do that.