Refactor Gemfile to consume .gemspec

To properly use a Bundler workflow that:

• consumes the Puppet source as a gem with a Gemfile like

source 'http://rubygems.delivery.puppetlabs.net/'

gem 'puppet', :git => 'https://github.com/Iristyle/puppet.git', :ref => 'd5a0a3d'

• In a Windows environment that requires platform specific gems like ffi
• Where the Bundler install specifies --system like bundle install --system --binstubs C:/cygwin64/bin where the Ruby distribution is a custom build that already incorporates vendored gems like win32-process, win32-service, win32-eventlog, win32-dir, win32-security and ffi
• For the sake of a workflow like ci:test:git in Puppet

This seems to require that the .gemspec in the Puppet source specifies all of the relevant dependencies when it is rewritten by Bundler to the gems/bundler/gems directory like:

# TODO: copy paste code in from a ci:test:git run in Puppet

Currently the Gemfile is able to resolve dependencies dynamically based on platform, but the .gemspec does not. Bundler doesn't use the Gemfile, so the current ci:test:git process emits messages for Facter dependencies during installation like:

Using win32-dir 0.4.9

Using win32-security 0.2.5

For Puppet to load properly in this setup, the bundle install must also emit messages for other gem dependencies like:

Using win32-service 0.8.8

One known way to fix this problem (there may be other hacks that can be made to ci:test:git) is to refactor the Gemfile and .gemspec so that all gem installation logic appears in .gemspec instead. Then Gemfile calls gemspec and consumes it. This enables the above workflow to proceed.

Note that this shouldn't impact the current gem build process at https://github.com/puppetlabs/packaging/blob/master/tasks/gem.rake. That packaging task builds a .gemspec dynamically for shipping that properly references gems as static dependencies for the sake of the 4 gem flavors we currently ship - x86-mingw32, x64-mingw32, universal-darwin and standard. Whatever changes are made should not break that process (this probably means that project_data.yaml should not be removed at this point.