Use commander for CLI interface.

We looked at Thor and GLI as well. We've had poor experiences with Thor
in the past so that was taken off the list. GLI was next up. We decided
it was a bit too heavy weight for us. We would have ended up moving lots
of parts around to namespace things cleanly.

At this point we considered how we wanted things to work. We spiked a
simple interface (ended up being a DSL). The resulting code looked very
much like how commander is setup. Instead of re-inventing the wheel,
just use commander for the CLI.
Local dev environments in Ruby 2.1.3
Fix binstub issues for CI.

Hosting our gem's executable in `bin` causes bundler binstub problems.
When running `--binstubs` with bundler it will overwrite the gem's
executable; causing a self referencing loop. To handle we can:

- Manually create the binstubs we want `bundle binstubs rspec-core`;
  however this doesn't preserve our `--standalone` flag :(
- Tell binstubs to install into another directory

Go with the later and use `sbin` for `stubbed bin`.
Include default RSpec configuration.
Include basic sanity check for executable.
Setup basic commander shell.

Implement the basic CLI interface for the `radius` tool.

This configures it as a class which defines it's available actions and
properties. However, these are all set on the class object instance.
This currently prevents any sort of useful instantiation. I am torn on
this approach, between due to how the commander DSL read vs works.

They use a singleton for their `Runner` which gets setup by these
methods. This makes it very difficult to create more than one CLI, it
also makes it difficult to create an implementation that uses instances
over this weird class singleton structure.

Hopefully we can re-evaluate this in the future.

This has full stack feature specs with it. It includes some helpers to
make working with subcommands easier.
Merge pull request #1 from RadiusNetworks/commander

Use [`commander`](https://github.com/visionmedia/commander/) for the CLI interface.

We looked at [`Thor`](https://github.com/erikhuda/thor) and [`GLI`](https://github.com/davetron5000/gli/) as well. We've had poor experiences with Thor in the past so that was taken off the list. GLI was next up. We decided it was a bit too heavy weight for us. We would have ended up moving lots of parts around to namespace things cleanly.

At that point we considered how we wanted things to work. We spiked a simple interface (ended up being a DSL). The resulting code looked very much like how commander is setup. Instead of re-inventing the wheel, we decided to just use `Commander` for the CLI.

In an effort to not include all of the Commander DSL on `main` we chose to **not** go with the ["Classic Style"](https://github.com/visionmedia/commander/#classic-style). We could have gone with the ["Block Style"](https://github.com/visionmedia/commander/#block-style) inside the script, which is probably how Commander _should_ be used, but it also doesn't fit well with us packaging this as a CLI toolset. This left the ["Modular Style"](https://github.com/visionmedia/commander/#modular-style).

It felt very strange to define all of the "CLI class" properties in the `run` method. One one level, this makes some sense. You could pass in all sorts of options, or even sets of commands, to then configure the CLI. In our case, most of these properties are relatively static. It "feels" more correct (for now) that these are defined at the CLI class level.

Ideally, defining these at the class level would mean instances of said class having all of those properties / actions set. Unfortunately, this is not how Commander works. It's DSL can be defined ANYWHERE. Ever place it is defined does the same thing. They all [delegate back](https://github.com/visionmedia/commander/blob/v4.2.1/lib/commander/delegates.rb#L8-L10) to the same static [singleton](https://github.com/visionmedia/commander/blob/v4.2.1/lib/commander/runner.rb#L42-L44)! :rage: 

Since :wrench: fixing Commander is out of scope for now, we are just going to go with the class level implementation and try to keep it compartmentalized as much as possible.

## Notes

- `sbin` is where binstubs are installed on CI

  Hosting our gem's executable in `bin` causes bundler binstub problems. When running `--binstubs` with bundler it will overwrite the gem's executable (`bin/radius`); causing a self referencing loop. To handle we can:

  - Manually create the binstubs we want `bundle binstubs rspec-core`; however this doesn't preserve our `--standalone` flag :disappointed:
  - Tell binstubs to install into another directory

  We'll go with the later and use `sbin` for `stubbed bin`. Locally, feel free to use `--binstubs sbin` and then make symlinks in `bin` to them to make your workflow the same.

- Feature specs

  These are both workflow and full end-to-end integration / acceptance specs. To handle shelling out, but not polluting RSpec output, we use [`Open3`](http://ruby-doc.org/stdlib-2.1.3/libdoc/open3/rdoc/Open3.html). Since we'll often have to run the same things, it is all wrapped up in a convenient helper under [`spec/support/subcommand.rb`](spec/support/subcommand.rb).

  One issue that came up is that the output with command is both indented AND uses terminal colors. I couldn't find any way to configure these and turn them off. Normally in testing you do care about whitespace, but you don't usually care about terminal colors. To preserve when we want colors we can get them with `Subcommand#raw_stdout`. Otherwise `Subcommand#stdout` filters them out. It does not however filter out the space padding. If you want to get rid of that, use `strip_heredoc` which is defined in [`spec/support/string.rb`](spec/support/string.rb) if it isn't already defined.