Gracefully handle invalid CLI options

This patch rescues the Exception from mixlib-cli so we no longer print a stack trace when given invalid options. This was particularly bad for users who expected java-style long options with a single hyphen for subcommands (i.e., `command -subcommand`). You now get a help message like this:

```
bundle exec bin/chef -foo                                         
invalid option: -foo
Usage:
    chef -h/--help
    chef -v/--version
    chef command [arguments...] [options...]


Available Commands:
    exec        Runs the command in context of the embedded ruby
    gem         Runs the `gem` command in context of the embedded ruby
    generate    Generate a new app, cookbook, or component
    shell-init  Initialize your shell to use ChefDK as your primary ruby
    install     Install cookbooks from a Policyfile and generate a locked cookbook set
    push        Push a local policy lock to a policy group on the server
    verify      Test the embedded ChefDK applications
```

Fixes https://github.com/opscode/chef-dk/issues/158

/cc @opscode/client-engineers 
Did you manually test this case?  I only ask because I am unsure of how mixlib-cli handles sub-commands (`chef subcommand1 subcommand2...`)