Break generator commands into seperate files

This commit breaks the generator commands from one big file into several smaller ones, and requires them. As we expand the number of generators, we're naturally going to wind up having more than
a handful - which makes the giant file, and its equally large rspec test, unwieldly.

In addition, it adds Guard support (for faster test results) and fixes a bug where the error handling in CookbookCodeFile descendents triggered hard failure in getopt due to lack of passing the params
in. This caused tests that were run with an rspec option to fail, as the repeat call to parse_options would pick up the default argv, rather than the mocked argv supplied in the specs.

No changes to the code happen at all, other than location and the small bug fix.
@sethvargo @adamhjk I don't think autoload is the correct answer or will even be necessary.

First of all, running `knife -h` doesn't tell you how fast `chef -h` will run, and unless you use the profiler, you won't learn anything that you can apply to the general case. I can tell you based on a lot of benchmarking and profiling I've done in the past that probably 1/2 of the time in your example is rubygems backtracking to find the correct set of dependencies, a problem we solved w/ appbundler in ChefDK.

Secondly, ChefDK already has a custom autoload-like implementation for the CLI, here: https://github.com/opscode/chef-dk/blob/master/lib/chef-dk/commands_map.rb and here: https://github.com/opscode/chef-dk/blob/master/lib/chef-dk/builtin_commands.rb Since we wrote it ourselves, we get to include the command name and description and also control when loading gets triggered, which means we can generate the help output without loading anything (for whatever reason, this is the benchmark people always use to demonstrate CLI performance).

Finally, I'm not sure that `require` has O(n) performance any longer (as of ruby 2.0 or 2.1), and in any case I'd guess that the actual performance impact is negligible if you measure it with a profiler.

BTW, the current performance of `chef -h` is quite good:

```
time chef -h > /dev/null
chef -h > /dev/null  0.08s user 0.01s system 97% cpu 0.099 total
```

`chef generate` loads chef (the gem) so it's a fair bit slower, but autoload wouldn't help that, and the performance isn't too bad anyway:

```
time chef generate -h > /dev/null
chef generate -h > /dev/null  0.73s user 0.11s system 99% cpu 0.837 total
```