Always raise exception when uploading a metadata frozen cookbook

Most community tools (including the Chef-shipped `knife`) raise an exception when attempting to upload a frozen cookbook when the same version already exists on the remote Chef Server. Berkshelf, however, quietly catches the exception and continues. The user must specify the `--halt-on-frozen` flag to overwrite. There are proposals to change the output message to something more descriptive, but I don't think that's in the best interest of the project.

This differential in mental model is the source of many issues on Berkshelf regarding the behavior of the uploader. For example, when a user is working in development and uploading to the Chef Server, Berkshelf will happily freeze and ignore future changes. This makes for quite the head-scratching situation.

Here, I'm proposing a simple fix that will align Berkshelf more with other community tools, without changing the underlying behavior. I think it's a best practice to freeze any uploaded cookbooks. However, I don't think requiring the user specify a flag to see the failures is a good idea.

This commit removes the `--halt-on-frozen` flag entirely and Berkshelf will always raise an exception if the cookbook is frozen (in line with other community tools). Should a user wish to overwrite this behavior, he may specify the `--force` flag (which already exists). This tells Ridley to overwrite the frozen version.

So there are now two pathways for a user to work in development with a remote Chef Server:

1. Getting the exception and then `--force`ing:

    ```text
    $ berks upload
    # ...

    # (makes changes)

    $ berks upload
    Error: the cookbook 'foo' is frozen at 1.0.0 on the remote server. Re-run with the --force flag to overwrite

    $ berks upload --force
    # :)
    ```

2. Using `--no-freeze`:

    ```text
    $ berks upload --no-freeze
    # ...

    # (makes changes)

    $ berks upload --no-freeze
    # :)
    ```