Removed unused methods

* `unsetvar()` was ommented that it was only used in tests and the only tests that used it
test it, so it isn't needed to actually test things.
* Since the `scope_path()` method isn't actually used for looking up the
variable, there is no guarantee that it is the actual path of scopes
used.
Fixed error reporting when appending

There was a pointless raise that a test thought it was checking for, but
a different error was being raised than was intended. The logic also
used a lot of "unless"es which made it hard to follow at times, so
changed them to "if".
Removed dynamic scoping

Removed dynamic scoping code and related acceptance tests that checked
that deprecation warnings were issued about accessing variables via
dynamic scope. Since there is no dynamic scope anymore there is no
warning.
Moved full scoping tests to integrtion

Since these are using the entire parser/compiler system they don't
really qualify as unit tests.
Fixed += op changing arrays in outer scope

The += operator was changing the value of the variable that it was
supposed to clone when the value was an array.
Added tests to cover old dynamic lookup

These test cases cover what happens in what used to be dynamic lookup
situations.
Added tests around enc usage

Scoping for classes included by an ENC follow some rules that are not
immediately obvious. These tests should nail down and clarify that
behaviour
(#14072) Allow faces to inline global setting docs

Add `display_global_options` to Face DSL.
Add `environment`, and `modulepath` as display_global_options for existing
module face.
Add `type` for typed settings.
Add display_global_options to exising help and man faces.
(#13948) $libdir not in $LOAD_PATH

Change :call_on_define to :call_hook with values of
:on_define_and_write, :on_initialize_and_write, and :on_write_only.
Make hooks for $libdir, $factpath, and $storeconfig new value of
 :on_initialize_and_write to take advantage of bootstrapping sequence.
Change Puppet::Util::Settings to call hooks on settings designated as
:on_initialize_and_write immediately after initialing default
application values.
Deprecate Puppet::Util::Settings::StringSetting#call_on_define.

This change is backward compatible, although :call_on_define is
deprecated and should be changed to :call_hook => :on_define_and_write.
This change should also be forward compatible if we decide to call hooks
at other portions of the application bootstrapping lifecycle.

This commit fixes the problem that the default libdir was not being
added to Ruby's $LOAD_PATH properly.

Prior to this commit, the hooks for $libdir and $factpath were not
getting called unless explicitly overridden in the code. This meant that
the default $libdir was not part of $LOAD_PATH and the default $factpath
was not searched for facts.  This commit fixes those problems by
enabling settings to declare when the hook should be called.  A hook can
be only only when a value is overwritten (:on_write_only), which is the
default. A hook can be called with the default value when when the
setting is defined (as soon as Puppet::Util::Settings.define_settings is
called) (:on_define_and_write), in addition to any time the value is
overwritten. A hook can be called with the default value during
application initialization (:on_initialize_and_write), in addition to
any time the value is overwritten.

We've added the call to the initialize hooks in two places because we
have to deal with the bootstrapping of applications. We need to attempt
to parse command line options and the configuration file and call the
hooks. Then we need to do it again after the application is loaded
because it could very well have changed important things like $vardir,
which generally affects $libdir.
Add ability to filter resource_type output by type

Would really love to think of a different word to
use for one of those instances of 'type'.  Basically
this allows you to filter the resource_type output
by classes, defined_types, or nodes.  It's a small
part of the data separation / lowrider project.
(#14137) resource_type serialization naming conventions

This commit attempts to bring the serialized representation
of resource_type objects into better alignment with naming
conventions that we've established in our documentation
and elsewhere.  In particular:

* "resource_supertype" => "kind"
* "hostclass" => "class"
* "definition" => "defined_type"
* "arguments" => "parameters"

These changes only affect the serialization (#to_pson/#from_pson).
The internal representation still uses the old terminology.
Ideally we'd just change the internals to conform to the
naming conventions, but that is a larger changeset than we
can reasonably tackle right now.
Merge pull request #721 from pcarlisle/file_terminus

Add default_file_terminus setting
Cleanup some dumb tests in settings specs

Patrick found a few things in the settings_spec tests that
weren't really testing what they claimed to be.  Minor
fixes to account for those.
Merge pull request #703 from cprice-puppet/feature/master/filter_resource_type_by_type

(#14137) usability improvements to resource_type API
Merge pull request #690 from jeffweiss/ticket/master/14072_allow_faces_to_inline_setting_docs

(#14072) Allow faces to inline global setting docs
Merge pull request #702 from jeffweiss/ticket/master/13948_libdir_not_in_load_path

(#13948) $libdir not in $LOAD_PATH
Merge branch 'puppet-cleanup/master/bad-settings-specs' from cprice

Conflicts:
	lib/puppet/util/settings.rb

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Merge branch 'feature/13970/remove-dynamic-scoping' from zaphod42

Conflicts:
	lib/puppet/parser/scope.rb
	spec/unit/parser/scope_spec.rb

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Munge settings in value instead of set_value

Before this munging happened before variable interpolation in settings. This
made it impossible to expand a path properly if it contained a reference to
another setting. By munging after variable interpolation we can solve this
problem.
Add a path type to settings

This path type will expand all paths in a string separated by
File::PATH_SEPARATOR, but does not add the paths to the settings catalog. This
helps the most on Windows, where it means that paths given to settings will
consistently use File::SEPARATOR, no matter how they were entered by the user.