Revisit multiple option handling, particularly --peer

[christophermaier]

In the past, we've used a space-delimited list of peer addresses as the value to the --peer option when starting up a Supervisor (including in our own provisioning (private link). The way the code is written, and based on how Clap handles argument parsing (which may have changed recently?), only the first peer address is actually used.

Passing the --peer flag multiple times, however, successfully accumulates all peer addresses.

We should survey our documentation for --peer in particular, but all multi-valued options across our CLI, to ensure that users are not confused (initially, there was some confusion over whether comma-delimited values would work, too). We should also update our provisioning code accordingly.

[rsertelon]

There's --bind that would benefit from that too (see #2221 and #3106).

Also, I've opened an issue on the clap-rs crate repository about these issues, where the maintainer points to what you're suggesting (clap-rs/clap#1125)

[mpeck]

multiple options can be specified using a space delimited list or by specifying the option multiple times, hab sup run --peer 1.1.1.1 2.2.2.2 3.3.3.3 or hab sup run --peer 1.1.1.1 --peer 2.2.2.2 --peer 3.3.3.3