(#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.
(#19713) Add tests for non-String exec commands

Add tests that ensure `exec` resources raise errors if the value given for
`command` is not of type `String`.
(#19713) Validate exec commands to be type String

The `exec` type calls a pile of string-specific methods, such as `scan` and
`split`, on the value of `command`. Validate that `command` is of type `String`
so that Puppet can fail with a helpful message if the value was passed as a
type such as `Array`.
Merge pull request #1525 from Sharpie/19713-exec-commands-must-be-strings

(#19713) Validate exec commands to be type String
(maint) Fix exec type test failures on 1.8.7
Merge branch 'maint-exec_type_test_failures_187'
(#5752) Handle read errors in parsedfile provider

The parsedfile provider can handle multiple targets (multiple files,
multiple crontabs, etc) but the provider does not handle the case when
retrieving a target during prefetch fails. When the provider does only
handle one target this doesn't really matter because a possible error is
caught at a higher level (inside Puppet::Transaction). But if the
provider handles multiple targets, one error will cause the whole
prefetching method to fail and all targets are treated as empty.

One example of the issue is described in #5752: Multiple crontabs are
manages with crontab resources and one cronresource describes a
cronentry of an absent user. Because prefetching the crontab of the
absent user fails, the crontab of *all* users are purged and every
crontab entry which is not managed by puppet is lost.

The change now handles the error inside the parsedfile provider itself,
so only the target that is causing troubles is treated as empty.