(#7316) Refactor listing and requiring of applications

Previously, the logic for listing and requiring applications was in two
places, CommandLine and Application, respectively.

The CommandLine contained logic, basically duplicated from the
Autoloader, to walk a search path and generate a list unique
applications relative to 'puppet/application'.

The Application contained logic for requiring the application from
'puppet/application', duplicating the logic from CommandLine.

This commit moves the logic for listing available applications to the
Application class, which delegates to its autoloader. Note the
autoloader already takes gem and module paths into account, so no change
in functionality there.

This commit also deprecates the CommandLine available_subcomands
instance and class methods.
(#7316) List faces using an autoloader

Previously, calling Puppet::Interface.faces generated a
different list of face applications than those included in
Puppet::Application.available_application_names, since the former only
considered the $LOAD_PATH, and the latter used an Autoloader, which
includes gem directories and the current environment's modulepath.

From what I can tell, the method is never used, as puppet itself
accesses faces via Puppet::Interface[name, version] method. However, if
someone had called `faces` it would have excluded faces that could be
loaded via require.
(#7316) Append module plugin directories to $LOAD_PATH

Previously, face applications delivered as a module could not be loaded.
This is because FaceCollection has problems loading code. For one, it
require's faces and actions within, but load's actions that reside in
different files. So it conceivable that a reloaded face application
could run with older faces, but newer actions.

Second, if we load the face, it will call Puppet::Interface.define,
which will check if the face has already been loaded by calling
FaceCollection[name, version]. But that will attempt to load the face
that we're currently loading, getting into an infinite loop.

Third, the help face application gets a list of available application
names from Application. This list includes applications from gem and
module paths. However, the help face application fails to load faces
which reside in the modulepath, since it's using require and not going
through the Autoloader.

While faces could be modified to use an Autoloader, the longer term plan
is to stop pretending we can reload code in ruby, i.e. always require
based on the current $LOAD_PATH.

This commit adds a `each_plugin_directory` method that yields each
module plugin directories based on the current environment. It also
modifies the CommandLine to append those directories,  unless we are
loading the master or agent applications.

In the case of an agent, the libdir is always in the $LOAD_PATH, and it
will load pluginsync'ed files from there. This aspect of #4248 has been
fixed for sometime.

In the case of master, we compile catalogs in the context of the
client's environment, not necessarily the environment the master itself
is configured to use. As such, we only want to autoload custom functions
from those modules, not require them. In other words, we don't want those
modules in the $LOAD_PATH to start with. This aspect of #4248 (the
ability to load utility module code from a custom function) is not
fixed, and can't really be fixed until we move to one process per
environment compilation.

In the case of apply, we compile catalogs, but always in its current
environment, so we can safely append to the $LOAD_PATH. And same for
face applications. As a result, the help face can load other faces from
modules.
(#7316) Warn if script action is reloaded

In commit 6f38feba for #12763, we no longer prevent actions from being
reloaded, e.g. during pluginsync. But this only applies for "normal"
actions, not script actions.

This commit makes a similar change for script actions so they're
consistent.

With that said, the whole reloading of actions is dubious. If the action
is declared within the body of the face, then the action will be
required along with the face, and neither can be reloaded. Only if the
action is in a separate file will it be loaded via the Autoloader, and
therefore be reloadable.

Also, it doesn't appear we can reload default actions, though we can
reload script actions (if they were originally loaded).
(#7316) Add acceptance test for loading face from module

This acceptance tests verifies that we can load a face application from
an environment-specific modulepath. It ensures the face is an available
application, that we can get help for the face, and that we can execute
a simple action, and an action that requires utility code to perform the
action.