Add the `trader` tool gem.

This tool will be our 2nd example using the BDD / TDD process.  It is setup
with some basic structure to facilitate the process without requiring lots of
extra custom configurations.

In this example, both Cucumber and RSpec will be used. We choose to use Cucumber
here to demonstrate it as a tool, and to show how the `aruba` gem makes it easy
to write public specifications for the tool.

Some basic setup for both Cucumber and RSpec have been included. See the
corresponding `cucumber.yml`, `.rspec-example`, and `spec/spec_helper.rb` for
details.
Start with a high level feature specification.

Again, we start with some general BDD. We add a high level spec to get all of
our parts wired up. The goal here is to make sure we have Cucumber working and
the executable tool setup.

Aruba is kind enough to provide us with all of the Cucumber steps that we will
need for the majority of our CLI tests.

Here we've added a very high level description of how the tool works (similar
to what's in the README). We then add the initial scenario of running the
command. Aruba has already added our `bin` directory to it's load path, so it
will look there to try to run it.

As with all feature specs that we are working we tag it with a `wip` flag.
Cucumber expects this to precede the scenario and begin with an '@'.
Add executable for the cli.

Here we add the `trader` executable for the CLI. We setup the shebang to
run the available version of Ruby. We also set the executable bit on it.

Print the usage when the executable is run. We can run this locally by
executing "bin/trader". Aruba has already adjusted our path for us, so it sees
the file when it runs the spec.

Lastly, the wip tag is removed on the spec as it is fully passing.
Add the next general usage job story.

For the scenario we provide some details via free form text on what the
job story actually is. We then write the scenario using the Aruba steps
to create files with specific content. The our executable is run and the
output is compared.

Once again, as this is a feature spec, we mark it with `wip` until the
feature is complete.
Write the desired implementation of the feature.

This is our chance to write the code we wish we had. It doesn't matter
if none of it exists. We will create it. This is our chance to define
our internal API for what objects we have, how we interface with them,
and what they return to us.

Our existing spec still passes; though the wip one fails. This is fine.
We expect the wip specs to fail on some commits, that's why we marked
them. Since our existing spec is passing we can safely commit this
partial feature implementation with out worrying that the existing app
is broken. We'll continue to follow this process as we build out the
features.