cli's help messages are too abstract, e.g. nothing toxic specific

out of #139 came an interesting point.
per @xthexder:

The cli is designed to be independant of what toxics are defined, so that if a new toxic is added, the cli and api will still work with older versions

interesting choice. this explains another gripe i had as a newcomer to this project: toxiproxy-cli only has help messages for highlevel operations (e.g. create and remove a toxic) but no help messages about which toxics you can add, what their attributes are, etc. It would be nice to be able to have toxiproxy-cli toxic help add list the available toxics and toxiproxy-cli toxic help add latency for example show details about how to add a latency toxic. With the current strategy of keeping the cli generic, this can't be done.
You could technically have the cli query the server for the available toxics, their attributes, which are required vs optional etc and then feed that back to the user, but I would argue that's getting a bit complicated and probably makes it quite hard to dynamically build optimized CLI experiences (see below)

If somebody upgrades their server to support new toxics or new toxic attributes, then it seems very reasonable that they also update the cli as well. given proper packaging / install script /.. this is no extra effort at all.

this way the cli can "truly" support the toxics. and not only could it display more useful help messages, it could also provide a CLI experience that's more optimized. e.g. instead of:
toxiproxy-cli toxic add [command options] <proxyName> with options like --type value, -t value and --attribute value, -a value

you could do:
toxiproxy-cli toxic add [command options] latency <proxyName> with options like --latency and --jitter

this CLI approach seems more user friendly IMHO, I would argue it's a good thing that the cli is optimized for the terminology of the toxics etc instead of trying to be more of a generic json encoder for toxic attributes. If people want that, they can use curl ;)

anyway, please consider this as the way i intend it: constructive feedback.
this project is pretty sweet and I hope to contribute as much as I can (first with some thoughts and ideas, and later hopefully with code as well)

Start by locating the toxiproxy-cli toxic help and toxic add entry points, then compare the current generic command options with the proposed latency example. Done would mean the CLI can explain available toxics and their attributes and provide toxic-specific add options, with the scope and compatibility approach resolved.