Fix PUP-1568 - no success variable anymore

In the refactoring within 000b8fef the success variables was
removed. So the error message shouldn't anymore use it.
Fix broken spec & wording of error message.

While working on 658f1237c1596a6f735b7b707130fc0897a1a113 I stumbled
accross another messages that would say 'with error code false', which
doesn't make a lot of sense. Also the plain 'expect raise_error' was
masking another problem with tests. One should always only look for the
exact expected error and not just general for any kind of error.
(PUP-1220) apply proper scoping rules to scope#to_hash

The fix for #1427 added an instance method to the scope class
for exporting all variables from the local scope. This method
apparently re-implemented the dynamic scoping rules.

When those were removed, the #to_hash method was left as was.
As a result, dynamic scoping still worked from within templates,
when using the @variable syntax in the erb code.

Fix this by using the new #enclosing_scope method so that proper
scoping rules are used instead.
(PUP-1220) make the dynamic scoping fix for #22800 flexible

As suggested by Henrik Lindberg, make the parser only behave correctly
when parser=future is configured. If working manifests rely on the
regression, the next point release won't break them. Instead, users can
test for this using the configuration setting.

The next major release should adopt the fix as standard behavior and
the legacy support should be removed. Since the variable lookups in
templates relies on the accessing of local attributes, there is no
way to issue deprecation warnings to users.
(PUP-1220) optimize template scoping fix

Following enhancements as suggested by Erik Dalen, Andy Parker et al.
* prefer Puppet[:parser] over Puppet['parser']
* cache the config value of Puppet[:parser]
* pick the future vs. legacy branch only once per template
(PUP-1510) Fixed forcelocal bug with ensure => absent

The forcelocal option was referencing a command that was not
previously defined which was throwing an exception.  The forcelocal
feature does not need to use a special command to delete local users,
only to add them.  So the special logic for delete was removed and
forcelocal now uses userdel to ensure absent on a user.
(maint) Improve Puppet::Util::Docs.scrub's handling of one-liners

One-liner handling wasn't behaving as expected. Sometimes one-liners are
buffered with extra newlines before and/or after, and in these cases, scrub
wasn't catching the leading whitespace.

This commit makes it behave as intended, and adds a test showing the intended
behavior.
(doc) Fix a typo in docs for the include function

There is a typo in the documentation for the include function.
This patch merely fixes that typo.
(maint) Banish "configuration parameter"

They are called settings!

Note: Two spec files relied on the wording of an error message I changed.
I revised them to find the new wording.
(PUP-1735) Reimplement deprecated Puppet::Node::Environment.current

Puppet::Node::Environment.current is used in some external code, so
reimplement it, linking to the context lookup for the current environment
and issue a deprecation warning.
(pup-1505) Correct require

The previous patch for pup-1505 changes to use a facter
top-level method (rather than one buried inside facter) but
neglected to update the require to match. This patch updates
the require.
Merge pull request #2384 from kylog/issue/pup-1505/fix-require

(pup-1505) Correct require
Merge pull request #2382 from domcleal/tickets/master/pup-1735-current-env

(PUP-1735) Reimplement deprecated Puppet::Node::Environment.current
(PUP-1707) Ensure ERB generated help content is UTF-8 encoded

Previously, `env LANG=C bundle exec puppet man module` could not output
non US-ASCII characters correctly due to two issues.

First, puppet uses ERB generate the help output. Since the templates did
not include a magic encoding comment[1], ERB would set the string
encoding of the content it generated to `Encoding.default_external`, which
in the case of LANG=C and ruby 1.9 is US-ASCII.

When generating ERB help output for the `module` application, the resulting
byte stream would be correctly UTF-8 encoded, but `String#encoding` would
report US-ASCII. So later when we tried to perform a regex against it, we'd
get the `invalid byte sequence in US-ASCII` error.

The second issue was that HavePrintedMatcher redirects stdout and stderr
to an instance of StringIO, whose default encoding was
`Encoding.default_external`. When we try to apply the regexp to what was
written to stdout, it would again fail, because the string was UTF-8
encoded, but reported itself to be US-ASCII.

This commit sets the ERB magic encoding comment, and sets the StringIO
encoding to 'UTF-8'. A test can override this behavior if desired within
the `expect { ... }.to have_printed` block.

[1] https://github.com/ruby/ruby/blob/v1_9_3_484/lib/erb.rb#L63-L68
Merge pull request #2386 from joshcooper/issue/master/1707-erb-encoding

(PUP-1707) Ensure ERB generated help content is UTF-8 encoded
(maint) Make setting not screw up when interpolating a false value

This was a class nil/false screwup.
(PUP-1707) StringIO#set_encoding doesn't exist in ruby 1.8

Only call the method if the object responds to it.
Merge pull request #2365 from alexharv074/fix_typo_in_include_doco

(doc) Fix a typo in docs for the include function
Merge pull request #2368 from nfagerlund/maint_configuration_parameter

(maint) Banish "configuration parameter"
Merge pull request #2361 from nfagerlund/maint_scrub_improvement

(maint) Improve Puppet::Util::Docs.scrub's handling of one-liners