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.
In CLIs, `require` is most certainly not ideal. "Broken" is a strong word, but we really care about load time...consider the Windows folks. Each file you require is added load time for even the simplest CLI commands:

```text
$ time knife -h
knife -h  2.01s user 0.39s system 89% cpu 2.679 total
```

We drastically reduced the initial loadtime in `berks` commands by ~3.5s just by switching from `require` to `autoload`. 

In my opinion, this is more about "delight" than "preference". Why should we require the user load every file when we just want to perform a single command? We should not be trying to optimize for how pretty the code looks - we should optimize for our users. Since we envision this tool to be a singular way to interact with Chef in the future, I fail to understand the lack of concern for speed of execution. As the number of files grows, the load time increases. Almost every large CLI-based application (see Rails, Berkshelf, Knife) has learned that more files == more load time. I love that you have split the commands into individual files, but that comes at an added cost.

The other problem with `require` is illustrated by this comment - you must manually declare your dependency graph at the top of each file. It makes refactoring significantly more difficult. And, each time you require a file, Ruby inefficiently loads it. Under the hood (translating the C to Ruby), this happens:

```ruby
def Kernel.require(filename)
  unless @loaded_files.include?(File.expand_path(filename))
    magical_method_to_load_the_file(filename)
    @loaded_files.push(filename)
  end
end
```

`@loaded_files` is an **Array** of filepaths. Once you have a fairly large number of requires, array lookups become expensive. Well, they are always expensive (`O(N)` in this case), but as N increases in size, `Array#include?` becomes rather inefficient. There have been quite a few blog posts on this subject.

TL;DR I do not think we should do what "feels right" to us - we should do what will be the fastest and most delightful experience for our users.