(maint) Remove dead dependency

The sys-admin gem is no longer used.
(FACT-567) Support bundler workflow on x64

This commit moves windows gem dependencies back into the Gemfile
because of problems trying to express dependencies for x86 and x64
simultaneously. For example, in ruby 1.9, rubygems does not know about
the x64_mingw platform. Also win32console is only a dependency in ruby
1.9 x86, but not in ruby 2 x86 or x64.
Merge pull request #692 from joshcooper/ticket/facter-2/FACT-567-support-bundler-x64

(FACT-567) support bundler x64
(FACT-567) Restore Windows gem package dependencies

The gem packaging (rake package:gem) and the bundler (bundle install)
workflows can be driven by the same ext/project_data.yaml file for
simple use cases like the CFPropertyList gem on darwin.

However, it doesn't work for Windows gem dependencies across different
ruby versions (ruby 1.9 x86 and ruby 2.0 x64) and windows architectures
(x86 and x64).

For example, the following will fail on ruby 1.9 x86:

    platform(:mingw, :x64_mingw) do
      gem 'ffi'
    end

Because only bundler version 1.5.0 and up understand the `:x64_mingw`
platform[1]. Running with an earlier version of bundler will fail
hard with '`x64_mingw` is not a valid platform.'

Another issue is that the current packaging workflow assumes the same
gem, e.g. `ffi`, isn't expressed across multiple platforms, e.g.
x86-mingw and x64-mingw. If you do this in project_data.yaml, then
during a `bundle install` we effectively end up doing:

    platform(:mingw) do
      gem 'ffi'
    end
    platform(:x64_mingw) do
      gem 'ffi'
    end

which results in warnings like:

    Your Gemfile lists the gem ffi (~> 1.9.3) more than once.
    You should probably keep only one of them.  While it's not
    a problem now, it could cause errors if you change the
    version of just one of them later.

Alternatively, you can do `gem 'ffi', :platforms => :mingw, :x64_mingw`,
but the project_data.yaml file is not setup to express dependencies like
that.

Commit 72f820d01 moved windows dependencies from project_data back to
the Gemfile. As a result, windows specific facter gems did not contain
any dependency info. So doing a `bundle install` on code that depends on
facter, would not include the transitive windows gem dependencies, e.g.
ffi.

This commit duplicates the windows gem dependencies in the
project_data.yaml. Also when using bundler on windows, we only pull in
dependencies from the Gemfile, but not project_data.yaml. Otherwise, we
would get the 'Your Gemfile lists the gem ... more than once' error on
all platforms.

As a result of this change, we need to keep the dependencies in the
Gemfile and project_data.yaml in sync. At a future date, we can look at
improving the packaging repository to handle more complex gem
dependencies.

[1] https://github.com/bundler/bundler/commit/facdbf0a962
Add LinuxMint to operating system facts

This commit was cherry-picked from 1938f39.

Conflicts:
	lib/facter/operatingsystemrelease.rb
	lib/facter/osfamily.rb
adding tests for LinuxMint facts

This commit cherry-picks ec6aed48

Conflicts:
	spec/unit/operatingsystemrelease_spec.rb
	spec/unit/osfamily_spec.rb
Merge pull request #695 from Whopper92/port_mint_facts

[FACT-465] Port Linux Mint facts and tests
(maint) Bump win32-security to at least 0.2.5

Versions of win32-security prior to 0.2.5 contained a bug on x64 due to
ulong being a 32-bit unsigned integer, whereas the OpenProcessToken method
takes a uintptr_t, which is 64-bit unsigned integer[1]

[1] https://github.com/djberg96/win32-security/commit/4af3625d61
Merge pull request #694 from joshcooper/ticket/facter-2/FACT-567-restore-gem-dependencies

(FACT-567) Restore windows dependencies during gem packaging
(FACT-335) implement GCE virtual fact
(FACT-570) Remove windows-pr dependency

Previously, we used the windows-pr gem to detect which windows version we
were running on, and then either called into the win32-security gem for
windows versions < 6.0 (2003), or used windows-pr gem to determine if
we were running with elevated privileges.

However, the `Win32::Security.elevated_security?` method now correctly
handles Vista and up, so we can just call that directly, avoiding
windows-pr, and in the process eliminating win32-api.
(maint) Ensure gems are not required in Gemfile

Previously, I omitted the `require => false` line in the Gemfile,
which means bundler will magically require the library. That's ok
when running from source, but if Facter is not running from source
and forgets to explicity require a gem, then Facter will fail hard.

This commit ensure Facter explicitly requires all Windows dependencies.
(FACT-353) Set LC_ALL environment variable to "C" for child processes.

Adding LC_ALL => C for the with_env call in execute.  This will ensure
that child processes that do not check LANG will output using a C
locale if they respect LC_ALL instead.
Merge branch 'ticket/facter-2/FACT-570-remove-windows-pr' into facter-2

* ticket/facter-2/FACT-570-remove-windows-pr:
  (maint) Ensure gems are not required in Gemfile
  (FACT-570) Remove windows-pr dependency
(FACT-335) Add GCE metadata facts

Implementation derived from d7c863eb.
Merge pull request #696 from peterhuene/fact/353

(FACT-353) Set LC_ALL environment variable to "C" for child processes.
(FACT-593) Remove dependency on route binary from dhcp_servers fact

Previously, the dhcp_servers fact assumed that the route binary
was present, which it then tried to use to determine the primary
interface. This commit updates that fact to instead use /proc/net/route
to retrieve the same information.
Merge branch 'pr/697' into facter-2

* pr/697:
  (FACT-335) Add GCE metadata facts
  (FACT-335) implement GCE virtual fact
Merge pull request #699 from whopper/dhcp_route_fix

(FACT-593) Remove dependency on route binary from dhcp_servers fact
(maint) Avoid repeated fact evaluation against different loaders

Commit 4d937456e fixed an infinite recursion problem where Facter could load
a fact, e.g. ec2, and outside of the setcode body, the fact could reference
another fact, e.g. macaddress, that had not yet been evaluated. This results
in a fact cache miss, causing Facter to reload all facts, including the
original one, e.g. ec2, leading to an infinite loop.

The spec test was written to load nosuchfact.rb, which contained ruby
code that tried to resolve :nosuchfact, causing a cache miss, and
to ensure we didn't infinitely recurse.

However, the spec test did not account that there are two loaders in play,
so if you run:

    $ bundle exec rspec spec/unit/util/loader_spec.rb
    Already evaluated rest at /Users/josh/work/facter/lib/facter/ec2.rb:4, reevaluating anyways
    Already evaluated rest at /Users/josh/work/facter/lib/facter/ec2.rb:21, reevaluating anyways

The reason is because the spec test creates a loader that defines the
ec2 fact and its rest resolution. However, when nosuchfact.rb is loaded,
it calls Facter.value, which delegates to a different loader than the one the
test created. As a result, the ec2 fact is evaluated twice.

This commit simplifies the spec test to ensure that Kernel.load is only
called once for a given fact.