fix use C as default locale.

Currently facter sets only LANG environment variable, this does not
work on systems that have LC_ALL configured, because LC_ALL
have higher priority than LANG variable.

So the correct procedure is to configure LC_ALL=C instead of LANG=C.
change resolution_spec to test LC_ALL locale environment  var.
should configure LANG and LC_ALL.

refer to the pull request:
https://github.com/puppetlabs/facter/pull/497
(#22060) Revert "Faster MAC address load on Linux via sysfs"

This reverts commit 4b926d0df3bb02a0492908fd13479e0a148ae19e.
Author: Daniel Pittman daniel@puppetlabs.com
Date: Thu Jul 19 19:11:46 2012

While running `puppet agent --no-daemonize --debug`, and IFF somewhere in the
code I have $DEBUG = true, then if I Ctrl-C to kill the agent I see the
following exception:

  Exception `NilClass' at .../facter/lib/facter/macaddress.rb:19 -
  undefined local variable or method `path' for :Facter::Util::Resolution

This is followed by an "infinite" recursion / stackoverflow which impeeds
debugging other issues.

The enhancement introduced in 4b926d0 never actually took effect because this
exception was normally ignored causing the new (faster) MAC detection code to
always return nil. Spec tests were never written for this enhancement nor for
its interaction with ifconfig based MAC detection. Thus the safest path forward
is to just revert the offending commit.
Handle when facter is embedded in a jar
Merge branch 'pull-506'

This closes GH-506
Merge pull request #509 from mzeren-vmw/fix/22060/undefined_path_in_macaddress

(#22060) Fix undefined path in macaddress.rb
Merge pull request #497 from lmello/master

(#22097) This enforces using english locale before running facter commands.
Add gce facts from metadata server

Without this patch Facter does not populate the fact values with
information available in the Google Compute Engine metadata server.
This is a problem because end users will need to configure their
compute instances based on information provided by the metadata service.

This patch addresses the problem by reading the values from the metadata
server only if the DMI data contains the google compute identifier as
described in https://developers.google.com/compute/docs/instances#dmi
This behavior is similar to the AWS behavior and is improved over the
AWS behavior because we do not need to rely on a timeout to determine
the availability of the metadata service.  The DMI data alone is enough
to inform Facter of the metadata service presence.