The chef-solo binstubs need to use the Chef::Application::Client class

We really need to look at inverting the way that we invoke the Chef::Application::Solo class and then trampoline out of that into Chef::Application::Client when we are in zolo mode and not legacy chef-solo. Instead we should invoke Chef::Application::Client and then only trampoline out when we are in legacy mode, making legacy-mode the special handling case.

This means that command line parsing will have to be made consistent between the classes (and is probably a good thing -- reducing code duplication and interface drift between the two classes). The Chef::Application::Solo class should also likely have its CLI arguments removed, and all the code duplication should really get removed as much as possible.

In the end it would be best to have only Chef::Application::Client exist with special-casing around the legacy mode operation of chef-solo (although its also legacy and at some point we should deprecate that behavior, but that requires fixing the perf issues in ChefFS).

Start by tracing the chef-solo binstubs into Chef::Application::Solo and Chef::Application::Client, then compare how each class parses command-line arguments and handles zolo versus legacy chef-solo mode. Done would mean Client is the primary entry point, legacy mode is the special case, duplicated CLI handling is removed, and the two interfaces are consistent.