(PUP-3302) Fix resource when using directory environments

Before this fix when `puppet resource file` was being used set with
source defined puppet would error out because we need an environment
object in Puppet::Indirector::Request#environment= and instead of the
none environment being passed around it is passed as the string "none"
which is a directory environment that does not exist. This is what is
raising the EnvironmentNotFound error in puppet.

Instead of passing around a string we pass around the none environment
to fix the issue.
(PUP-3302) Fix Puppet Resource

@jpartlow and I paired on this issue.
Before this commit when using puppet resource with any resource that
went through the ral and needed a real environment would fail since the
default behaviour of Puppet::Resource::Catalog#initialize was to create
a new catalog used the None environment. In places where we were
performing `Puppet.lookup(:environments).get` on the None environment
puppet would fail, causing the none environment not found error to be
raised.

This commit changes the default behavior of Puppet::Resource::Ral#save
to create a catalog with the `current_environment` that is setup at
application initialization instead of the none environment. It also
makes `default_file_terminus` set to `file_server` in
`Puppet::Application::Resource` to make `puppet resource` act like
`puppet apply`.

We wanted to make sure that this change was not going to harm any other
parts of the puppet codebase and at least in puppet the ral is only used
when using `puppet resource`. We do not believe that it will have any
adverse effects anywhere else.
(Maint) Invert conditional to make it clearer

The behavior of environment bootstrapping is handled differently for
agent vs non-agent. The code that handled this expressed it as `run_mode
!= agent`, which became a little hard to parse when reading it. By
inverting the conditional it becomes a little easier to determine what
code path will be taken.
(Maint) Restore non-local behavior for resource

The puppet resource subcommand used to work with a remote file server
(`:rest`), a previous change made it behave more like puppet apply,
which uses a local file server. That wasn't a request from users, and it
isn't clear if it is actually the correct behavior. Normally it is used
for introspecting resources locally and so a local file server might
make sense. OTOH, remote is the behavior is has had for a very long
time...
(PUP-3302) Ensure resource uses given environment

Before this commit when puppet created the catalog in
`Puppet::Resource::Ral#save` with the current_environment instead of the
environment that the request passed into the indirector had requested.

This commit also modifies existing spec tests to show the cases where
the behavior that the commits in this pull request had fixed regarding
puppet resource.

Paired with @zaphod42
(PUP-3302) Remove redundant spec test

The integration test that specifically tried to cover recursion for the
file type was no longer needed. We could get similar coverage by simply
tightening up the evaluation environment in
spec/integration/type/file_spec.rb to not have any environments
available, which caused the code under test to show the mistake.
Merge pull request #3198 from demophoon/fix/stable/pup-3302-puppet-resource-directory-environments

(PUP-3302) Puppet resource fails when using directory environments