Knife prefers 'config.rb' to 'knife.rb' (but the latter is still supported and not deprecated)

1. `knife` now prefers `DIR/config.rb` over `DIR/knife.rb`. The reason for this change is to make the configuration less tool-specific, now that we have stuff like ChefDK and `chef-client` local mode which uses the same configuration as knife. `knife.rb` is not deprecated in any way at this time, though we should update tooling and documentation to prefer `config.rb` over `knife.rb`. At some future time we will likely add deprecation warnings for `knife.rb` and eventually remove it entirely (there isn't a technical downside to supporting `knife.rb` at this time, so a decision about how/when we do this comes down to ease-of-use, user confusion, the "old blog post" problem, etc.).
2. Knife's config finding/loading logic is extracted to a reusable component so other applications can use it (in particular, ChefDK is the immediate reason for this change). This requires some changes to avoid adding a dependency on Chef's HTTP code. We can revisit these changes based on the outcome of https://github.com/opscode/chef-rfc/pull/50 The big changes here are that fetching knife config via HTTP may have been supported but will not be after applying this patch (but see that Chef RFC for more info about that) and the "config file jail" which we added to isolate tests from the developer's knife.rb is effectively replaced with a `--dont-load-config` option which will skip config loading.
that reads much nicer, but we'll still have the double negative on line 283 (new code) (this: `!config[:dont_load_config]`). My (not super strong) opinion is that I'd rather have that be ugly and the help output a little less so than the other way around.