(#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.
(#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.
(#17190) Mark profiling APIs private

Until we make a specific decision that these should be available to
others, they are going to be made private.
(#17190) Handle errors during profiling

If an error had been raised in the profiled segment, the profiling
information would have been skipped, the sequence would not have been
updated and everything would start falling apart. This changes the
Measuring profiler to handle errors raised in the segment, but in so
doing has to stop using the Benchmark library and resort to Time.now.
(Maint) Extract time from profiler

The implementation for timing and logging the profiled information was
getting intertwined and messy. This extracts the timing and formating of
elapsed time into a Timer class that is used to time the segment.
(Maint) Cleanup some scope tests

Remove the naughty "should" and move away from instance vars.
(#17190) Profile function calls

This adds profiling of function calls on Puppet::Parser::Scope objects.
(#17190) Rename Measuring to WallClock

The Puppet::Util::Profiler::Measuring is better described as a wall
clock profiler. This renames it to that.
(#17190) Genericize output format of profiler

The output format of the profile messages was tied to the specific
profiler. This updates the message and internal structure of the
WallClock profiler to allow for making the entire flow of before and
after handling of the profiler generic.
(#17190) Extract abstract logging profiler

The logging and execution aspects of the WallClock profiler are going to
be useful in other contexts as well. This extracts out an abstract
Logging base class that provides a template method for WallClock.
(#17190) Add object count profiler

This adds a new (very experimental) profiler for tracking changes in the
ruby object space object counts. In order to use it right now, you'll
actually have to modify the code since there is currently no mechanism
for selecting the type of profiler to use. I'm also not certain that the
information this profiler collects is useful, but it might provide some
insight into the changes that different sections of code cause in the
number of objects in memory.
(Maint) Remove accidentally added debug line

I had added the debug of the request parameters at some point in order
to understand what they were. That had accidentally been committed.