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.
I thought about that for a second, the reason I chose to do it this way is because we can't hide config options from `--help` the way mixlib-cli works :frowning:, and I wanted to make sure `chef-client -h` output was as clear as possible. I'm not dead set on it though.