(#18986) Write to the console using Unicode Win32 APIs

Previously, puppet on windows could not output unicode characters to the
console reliably, such as the box drawing characters used by the module
tool when displaying dependencies.

Ruby 1.8 uses the ANSI Win32 APIs, e.g. WriteConsole, to write to the
console. However, it uses the current console codepage. So if the current
codepage cannot handle the unicode character we're trying to write, e.g.
cp1252, then it displays garbage.

Ruby 1.9 uses the Unicode Win32 APIs, e.g. WriteConsoleW. As such, it can
correctly write unicode output, without being sensitive to the current
codepage.

However, because puppet writes ANSI escape sequences, we use the
win32console gem to color the output. This win32console gem redefines the
stdout and stderr streams to accomplish this, and sadly uses ANSI versions
of Win32 APIs to write to the console. So it has the same problems as ruby
1.8.

This commit overrides the win32console classes, Console and IO, to ensure
the Unicode APIs are used. This enables us to display ANSI escape
sequences and unicode characters that may not be compatible with the
current codepage.

Longer term we should think about removing win32console gem altogether and
moving to ruby 1.9, as these hacks would no longer be required. Though
doing so would mean losing color output, or taking more drastic measures
like ansicon.
(#14985) Fix hiera lookup for calling_module and calling_class
(#14985) Fix hiera does not lookup calling_class and calling_module
(#14985) Fix test, return downcase values and check for nil scope.source
(#14985) Fix exception when nil is returned from inner scope
(#14985) Ensure hostclass finder is private

The nested definition of the recurse_for_hostclass method caused that
method to be created lazily and as a public method. By pulling it out to
be declared outside the calling method it can be made private and
created only once. It has also been renamed to show the intention
instead of the mechanism (recursion).
(Maint) Require Hiera::Config to avoid warning

When the hiera tests were run alone the puppet_backend_spec.rb issued a
warning:

  /Users/andy/work/puppet/spec/unit/hiera/backend/puppet_backend_spec.rb:25:
  warning: toplevel constant Config referenced by Hiera::Config

The warning was caused by a reference to Hiera::Config where Hiera was
defined, but Hiera::Config was not. This resulted in getting the top
level Config constant and a warning being issued. By requiring
hiera/config this problem is avoided.
(Maint) Use real scope in testing

Using the real scope is completely possible in these tests since it has
no dependencies on the outside world and is essentially a value object.
Therefore it should be used in the tests to make them more
comprehensive.
(#14985) Describe behavior of calling_(class|module)

The original tests for calling_module and calling_class used a mock,
when this is really just a value that can be setup. It also didn't
separate out and describe the behavior of the two pieces in the
variations in which they can come up. Specifically the difference
between a `define` and a `class` for the meaning of calling_class.
(Maint) Clarify scope lookup rules

The lookup rules for variables in the puppet language have always been a
bit hard for me to understand. I knew the rules as

  the current scope => inherited => node => topscope

but the code never seemed to express that clearly. This refactors the
`lookupvar` method to extract out a few pieces to make that clearer.
Specifically the mechanism for walking from a class to the enclosing
node (which is why this gets the name "two-step" by some people) has
been called out as a lookup of the `enclosing_scope`. Calling out the
enclosing scope as a specific lookup allows for getting rid of the
`:origin` part of the options hash, which was to provide a mechanism for
skipping over some scope objects.

This also tries to remove some duplication that was occurring because
there was not a consistent symbol table concept. It turns out that the
existing `Ephemeral` fits that nicely and so it now used as the scope's
symbol table as well as for the ephemeral variables.
(#14985) Preserve casing on looked up values

The initial fix for looked up values downcased everything that was being
returned. This causes problems when the data is not a string that the
previous behavior was to only do this for the calling_class and
calling_module. This commit us returns to that behavior.
(#16809) Use only one record_type in cron provider

The cronprovider defines two record_types :crontab and :freebsd_special
to handle the following crontab records:

    @daily /bin/my_daily_command
    0 0 * * * /bin/my_daily_command

This has a few issues:

a)
The merging of the name (the comment before the cronentry itself) and
the environment variables only happens for the :crontab record_type
but not for the :freebsd_special record_type so information may get
lost (#16809)

b)
When parsing an existing record the record_type can be automatically
determined (depending on which regex matched) but when creating a new
entry the record_type is undefined and the default :crontab is used.
So if a new cronentry is created with the :special property set it is
still treated as a crontab entry (so the to_line hook of the :crontab
record_type is used and not of the :freebsd_special record_type)
which is kind of confusing.

c)
It is really hard to change the time of a cronentry from the special
format to a normal format (or vise versa) e.g. if we already have the
following cronentry

    # Puppet Name: foo
    * * * * * /bin/foo

and we have defined the following resource

    cron { "foo":
      special => daily,
    }

the resource is treatd as in sync because the existing cronentry is
parsed as a :crontab record_type and this record_type doesn't define a
:special field that could be out of sync

This patch now only uses one record_type that internally parses the
timefield as either the old format (minute,hour,monthday,month,weekday)
or the special format. This way the above issues go away (but the
different to_line, post_parse hooks get a bit more difficult to handle
both entries)
(#16809) Refactor crontab provider with block_eval

Ruby 1.9 was failing to parse the previous implementation of the custom
crontab record_line provider methods. This commit uses the FileParsing
block_eval syntax to attach methods to the record_line object instead of
using anonymous procs.
(#16809) Remove refs to freebsd_special cron type

The legacy test::unit crontab tests contained checks for the
freebsd_special record line. Since those were not getting run by the
normal rspec coverage it got missed when the freebsd_special line type
was removed. This commit removes the outdated references.
(#17190) Provide more benchmarking info during compile

Many users find that they have very little insight into what the
compiler is doing and spending time on during compilation. This provides
extra logging for getting much finer grained information.
(#17190) Create Profiler components

The existing Puppet::Util#benchmark method makes it hard to easily put
in place because it does not retain the return value of the block
measured. It also does not give great control over whether or not to
profile, nor does it provide nesting information. This adds a profiler
structure that incorporates all of these features.
(#17190) Undo extra marking of benchmark output

The initial pass at adding compiler profiling added extra text to make
the benchmark output more "grepable". That isn't really needed once the
Profiler system is used.
(Maint) Attempt to clean up handler tests

The tests are using instance variables all over the place, which makes
them noisy for reading, and had useless tests for respond_to?. This
removes those tests, and tries to cut down on the noise some by making
the handler a let().
(#17190) Provide on-demand profiling of catalog compiles

The previous version of the catalog compile timings use the
Puppet::Util#benchmark system, which did not allow turning it on and
off. This replaces that system with the Puppet::Util::Profiler and
provides a parameter for requests called "profile" that can be used to
perform a profiled run.

Currently this logs to the debug output, but in the future could
reasonably send the profiling information elsewhere so that the user
does not need to have debug logging enabled in order to get profiling
information.

An example of how to use this. After a node has checked in and the
master has stored the facts for the node make another request from the
command line:

  curl -k -H "Accept: yaml" \
  'https://localhost:8140/production/catalog/aparker?profile'

The "?profile" is the signal to output the profiling information. The
master will output a log that looks like:

  Debug: 1.3.5 [2154751480] Compile: Evaluated node classes in 0.0000 seconds
  Debug: 1.3.6.1.1.1 [2154751480] Evaluated resource Foo[testing] in 0.0004 seconds
  Debug: 1.3.6.1.1 [2154751480] Evaluated definitions in 0.0006 seconds
  Debug: 1.3.6.1 [2154751480] Iterated (1) on generators in 0.0008 seconds
  Debug: 1.3.6.2.1 [2154751480] Evaluated definitions in 0.0000 seconds
  Debug: 1.3.6.2 [2154751480] Iterated (2) on generators in 0.0002 seconds
  Debug: 1.3.6 [2154751480] Compile: Evaluated generators in 0.0012 seconds
  Debug: 1.3.7 [2154751480] Compile: Finished catalog in 0.0004 seconds
  Debug: 1.3 [2154751480] Compiled catalog for aparker in environment production in 0.0291 seconds
  Debug: 1.4 [2154751480] Filtered result for catalog aparker in 0.0005 seconds
  Debug: 1.5 [2154751480] Rendered result in Puppet::Network::Format[yaml] in 0.0044 seconds
  Debug: 1.6 [2154751480] Sent response in 0.0000 seconds
  Debug: 1 [2154751480] Processed request GET /production/catalog/aparker in 0.0645 seconds

The outline style number that preceeds every line is to provide nesting
information. Ideally the time of the nested components should add up to
the higher level time.
(#17190) Improve output from profiling

The output for the profiling had an issue whereby the profiling run
identifier (the porting inside square brackets) followed the nesting
identifier. This caused a hard read output. This flips those two
components of the output to create:

  Debug: [2166677060] 1.3.6.2 Iterated (2) on generators in 0.0002 seconds
  Debug: [2166677060] 1.3.6 Compile: Evaluated generators in 0.0012 seconds
  Debug: [2166677060] 1.3.7 Compile: Finished catalog in 0.0004 seconds
  Debug: [2166677060] 1.3 Compiled catalog for aparker in environment production in 0.0290 seconds
  Debug: [2166677060] 1.4 Filtered result for catalog aparker in 0.0005 seconds
  Debug: [2166677060] 1.5 Rendered result in Puppet::Network::Format[yaml] in 0.0047 seconds
  Debug: [2166677060] 1.6 Sent response in 0.0000 seconds
  Debug: [2166677060] 1 Processed request GET /production/catalog/aparker in 0.0896 seconds

This also remove the profiler's dependence on the exact logging level to
use and instead makes it just call a method that it is given.