(PUP-3258) node exec indirector: default to environment, not its name

Nodes can be classified through a local executable that prints YAML with
a node specification. This is enabled through the node_terminus=exec option.
Since PUP-2519, this setting would break `puppet apply`. Trying to apply
any manifest would lead to Puppet applying the default environment's site
manifest instead.

The reason for this is that the node terminus will include the current
environment's name in the node lookup result. This in turn makes Puppet
look up the environment per name. This is not the desired behavior, because
Application::Apply performs the lookup and further operations with a localized
environment that overrides the site manifest.

Solved by including the current environment object in the returned node object
instead of its name.
(maint) reduce repitition in Application::Apply integration spec
(maint) Remove duplicate file handling code

The tests had their own way of creating files and directories for
testing. All of these different ways of creating files and directories
already existed in PuppetSpec::Files. This unifies them.
Merge branch 'pr/3144' into stable

* pr/3144:
  (maint) Remove duplicate file handling code
  (maint) reduce repitition in Application::Apply integration spec
  (PUP-3258) node exec indirector: default to environment, not its name

Closes GH-3144
(PUP-3351) Evaluate ENC classes in the correct order

Without this patch classes declared from an ENC are evaluated in the
wrong order.  This is a problem because classes declared without
parameters are evaluated prior to classes with parameters which causes
an Error: Duplicate declaration when the classes with parameters are
evaluated.  According to the code comments for the
`evaluate_node_classes` method, the expected behavior is that classes
with an empty set of parameters will not conflict with classes that have
declared parameters.
(PUP-3351) Test using example of problematic behavior

After talking with Reid Vandewiele, it turns out that the problematic
behavior isn't directly the order of the classes themselves. Previous
assertions that there are possible conflicts from the classes when they
were done in one order or another are incorrect. The classes, when any
have parameters, are kept by the node in a hash keyed off of the class
name, which means that there is no possibility of them creating a
duplicate resource error.

The actual usecase comes down to *how* parameterized classes vs
unparameterized classes are often used. A parameterized class can often
be simply a set of shared data that the unparameterized classes depend
on (or inherit from) parameterized classes.

This modifies the test case for the reordering change to provide an
example of the use case here.
Merge branch 'pr/3126' into stable

* pr/3126:
  (PUP-3351) Test using example of problematic behavior
  (PUP-3351) Evaluate ENC classes in the correct order

Closes GH-3126
Merge remote-tracking branch 'upstream/stable'

* upstream/stable:
  (PUP-3351) Test using example of problematic behavior
  (PUP-3351) Evaluate ENC classes in the correct order
  (maint) Remove duplicate file handling code
  (maint) reduce repitition in Application::Apply integration spec
  (PUP-3258) node exec indirector: default to environment, not its name