Conflicts:
	lib/puppet/type/file/source.rb
	spec/unit/resource/catalog_spec.rb

The introduction of composite namevars caused the resource title used in
resource aliases to be set as an array, even when the resource only had one
namevar. This would fail to conflict with non-alias entries in the resource
table, which used a string for the title, even though the single element array
contained the same string.

Now, we flatten the key used in the resource table, so that single element
arrays are represented as strings, and will properly conflict with resource
titles.

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

Types and parameters were registering their catalog as their expirer, so that
the catalog could expire them between uses. However, because catalogs are never
reused (and neither are types or parameters), there is no need to expire
anything. Thus, we remove the entire cleanup/expire logic from catalog, type,
and parameter.

Reviewed-By: Jacob Helwig <jacob@puppetlabs.com>

The method for adding class resources to the
catalog was only working in cases where the default
values weren't AST objects.  This commit fixes
this, along with the tests that were failing
and drew out the problem.

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

This is again done to make support for hiera easier.
The way we were handling lookup of resource defaults
was over-complicated.

This does a decent bit of cleanup overall, but primarily
focused on resource type defaults and how they get
set during compilation.

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>

* 2.6.x:
  (#7956) Porting cron tests
  (#7956) Port resource acceptance tests
  Readying for release of 2.6.9
  (#6854) Update Red Hat spec file
  Bumping release in lib/puppet.rb and updating CHANGELOG.
  Bumping RPM spec file to 2.6.9rc1.
  (#7506) Organize READMEs; specify supported Ruby versions in README.md
  (#6418) Make test 64118 more portable
  (#7127) Stop puppet if a prerun command fails
  Do not needlessly create multiple reports when creating a transaction
  (#4416) Ensure types are providified after reloading
  (#4416) Always remove old provider before recreating it
  Cleanup indentation, comment, and unused code

Conflicts:
	CHANGELOG
	README.md
	conf/redhat/puppet.spec
	lib/puppet.rb
	lib/puppet/transaction.rb
	spec/unit/configurer_spec.rb
	spec/unit/transaction_spec.rb

Before this change there were several problems with pre and post run
commands, logging, and sending of reports.

1. If a prerun command failed, puppet would attempt to apply the
catalog. Now puppet will not apply the catalog, but it will run the
postrun command and send the report (as it did before).

2. If a postrun command failed, puppet would not send the report. Sending the
report is now in an outer ensure block from the postrun command, so
postrun failures won't prevent the report from being sent.

3. Errors, e.g. Puppet.err, occuring during the prepare step, which
which includes plugin/fact download and prerun commands were not
appended to the report. Now the report log destination is registered as
early as possible, and unregistered as late as possible to ensure
Configurer errors that occur in the run method are included in the report.

4. The transaction was closing the Configurer's report destination out
from underneath it. As a result, postrun errors were not included in the
report.

Paired-with: Nick Lewis <nick@puppetlabs.com>
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>

Previously, the transaction would always create a report, which would
some times be overridden with a new report.

Now, the transaction optionally takes a report at initialization time,
and only creates a report of its own if none was provided.

Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>