Given that we have the 'include?' method, this feature
is unnecessary, and it makes sense to convert to more
ruby-like behavior.

Any code that previously checked whether lookupvar
(or the new []) returned :undefined should now check
whether 'scope.include?(var)'.  Thus, you can have
the same behavior, but it takes a bit different code
to get it.

Signed-off-by: Luke Kanies <luke@puppetlabs.com>
Reviewed-by: Nick Lewis <nick@puppetlabs.com>

The interface to scope is much clearer this way anyway,
but this is needed to integrate Puppet with Hiera[1].
It just provides hash-like behavior to Scope, which Hiera
and others can now easily rely on.

I also went through all of the code that used Scope#lookupvar
and Scope#setvar and changed it if possible, and at the same
time cleaned up a lot of tests that were unnecessarily stubbing
(and thus making it difficult to tell if I had actually broken
anything).

1 - https://github.com/ripienaar/hiera

Signed-off-by: Luke Kanies <luke@puppetlabs.com>
Reviewed-by: Nick Lewis <nick@puppetlabs.com>

This has been removed in favor of 'puppet parser validate <manifest>'.

Paired-With: Jesse Wolfe

The usestring parameter to lookupvar was objectionable for several reasons;
first, it performed a function orthogonal to the main purpose of the method,
second its default was the least common value, and third it was causing other
code to work for reasons that were not obvious (extlookup).

This refactor breaks the value-transforming function out into a seperate
method which allows the user to specify the value to be used in lieu of :undef
and removes the parameter.  The function, Scope#undef_as(default,exp) is
written so that it can be used in user code (templates, functions, etc.) if
needed.

This refactor will introduce a user-visible behaviour change in the case where
users were counting on lookupvar to return "" for undefined variables.  The
best solution is to have them use undef_as, replacing:

    lookupvar('myvar')

with

    undef_as('',lookupvar('myvar'))

(with the option to specify another default value if desired).  If this is too
objectionable, we could rename the existing lookupvar as raw_lookupvar and
define

    def lookupvar(v)
      undef_as('',raw_lookupvar(v))
    end

to restore the present behaviour.

In 2.6.x, this was upgraded from "info" to "warning". This change for
Statler escalates the warning to an exception which will abort the
compile. This makes compiling fail consistently when you try to use an
undefined class from any of: node classifiers, the class keyword, and the
include function.

Paired-with: Jacob Helwig <jacob@puppetlabs.com>

Manually Resolved Conflicts:
	lib/puppet/resource/type_collection.rb
	spec/unit/configurer_spec.rb
	spec/unit/indirector/catalog/active_record_spec.rb
	spec/unit/resource/type_collection_spec.rb
	spec/unit/transaction/resource_harness_spec.rb

This patch changes the internal representation of a file's mode to a
string instead of an integer. This simplifies the problem of displaying
the value consistently throughout all of puppet.

Doing a require to a relative path can cause files to be required more
than once when they're required from different relative paths.  If you
expand the path fully, this won't happen.  Ruby 1.9 also requires that
you use expand_path when doing these requires.

Paired-with: Jesse Wolfe

Replaced uses of the find, search, destroy, and expire methods on
model classes with direct calls to the indirection objects.  This
change affects tests only.

Changed the grammar so that the following "plural" constructs always
parse as an ASTArray:

- funcvalues
- rvalues
- resourceinstances
- anyparams
- params
- caseopts
- casevalues

And the following "singluar" construct never parses as an ASTArray:

- statement

The previous behavior was for these constructs to parse as a scalar
when they represented a single item and an ASTArray when they
contained zero or multiple items.  ("Statement" could sometimes
represent a single item because a single resource declaration could
represent multiple resources).  This complicated other grammar rules
and caused ambiguous handling of nested arrays.

Also made these changes to the AST class hierarchy:

- ResourceInstance no longer derives from ASTArray.  This relationship
  was not meaningful because a ResourceInstance is a (title,
  parameters) pair, not an array, and it produced complications when
  we wanted to represent an array of ResourceInstance objects.

- Resource no longer derives from ResourceReference.  No significant
  functionality was being inherited and the relationship doesn't make
  sense in an AST context.

- ResourceOverride no longer derives from Resource.  No significant
  functionality was being inherited and the relationship doesn't make
  sense in an AST context.

- Resource can now represent a compound resource instance such as
  "notify { foo: ; bar: }".  This saves the parser from having to
  use represent a statement as an array of objects.

- ASTArray's evaluate method never flattens out arrays of arrays.