goes red because we're really red here

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

This reverts commit 2865ca316e5b9512ffd8a7d784355e469a115717.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

this is also necessary for bundler-1.14.x

i'm still not entirely clear why we ever needed all the fussy software gem
configs or what the build-chef / build-chef-gem infrastructure ever
did for us.  it seems to have been mostly micro-optimization around
building the software gems before bundle installing the project in order
to take advantage of git caching.  i aggressively don't care about that,
this is quite fast enough.  we can install nokogiri and libgecode early
and that should take care of 98% of the build optimization issue.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

See the PR comments for more philosophical background.

This simplifies the external tests.  The major feature here is that
halite, poise, chefspec, etc are removed from the Gemfile.lock and
the transitive Gemfile splicing is gone from the external tests.

We're back to simply tracking master on external projects and bundle
installing without locks and going red if the break.  Those external
projects should all similarly track master of chef/chef to reduce
the possibility that they break us here.

This also bumps bundler to 1.14.x and unblocks us there.

It continues to simplify our use of bundler to be more mainstream and
less impenetrable.

There was some crazy shit that I found where I had to remove env vars
like BUNDLE_ENABLE_TRAMPOLINE and the BUNDLE_IGNORE_CONFIG and
BUNDLE_FROZEN env vars in appveyor along with the .bundle/config frozen
setting were necessary to unbreak appveyor.  We seem to have gotten
very far afield of standard bundler usage and it was breaking in strange
to debug ways.

Oddly enough this exposed weird errors in the
chef-config/spec/units/fips_spec.rb tests where we need to require the
"win32/registry" file there now even though I can't figure out why that
broke or how it was working previously.

Also, adding x64-mingw32 to x86-mingw32 was necessary to test in
appveyor on 64-bit windows (I tried universal-mingw32 and that failed)
which seems obvious and is another case that I don't understand how it
was working in bundler 1.12.x

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>