[chfsx]

This picks up the idea of #7897 by @daniwe4: php cli/setup.php status gets a -f option to only
show a part of the status. While rebasing #7897 onto trunk I measured where the command actually
spends its time, and that led to a different implementation, so this is a new PR instead of an
update of the old one.

Where the time goes

Measured on a fresh trunk installation with 16 plugins, best of five runs:

Call	trunk	this PR
status	0.341 s	0.150 s
status --no-legacy-plugins	0.105 s	0.107 s
status -f database	–	0.055 s
status -f config.common	–	0.059 s

Starting the CLI alone takes about 0.05 s, collecting the metrics of all core agents about 0.06 s.
Most of the rest was spent looking up the agents of the plugins: for every plugin the finder went
through all ~20 000 classes of the composer classmap, and before that walked recursively through
every file below Customizing/global/plugins, including the vendor directories of the plugins.

What changes

Find the agents of all plugins in one pass (ImplementationOfAgentFinder)

• The plugin names are read from the fourth directory level with glob() instead of a recursive walk.
• The agent classes of all plugins are found in one pass over the classmap and grouped by plugin.
• This speeds up every setup command that loads the agents of the plugins (status, update,
  achieve, migrate), and the gain grows with the number of plugins.
• getPluginAgent() no longer picks up classes of another plugin that happens to contain a
  directory with the requested name.

Filter the status command by the path of a metric (StatusCommand)

• status -f database.version only outputs that metric, status -f config.common the common
  part of the configuration section.
• The first part of the path names an agent, and only that agent is asked for its status. For an
  agent of the core, the agents of the plugins are not looked up at all, so a filtered call is
  about as fast as starting the CLI.
• If the path does not exist, the command says so and exits with 1 instead of throwing. Below an
  agent, the message names the keys that are available at that point.

Differences to #7897

#7897 made the values of metrics lazy: Metric and every Storage::store*() method took a
callable instead of a value, and stability and type became enums. With the agent selected by the
filter, that saves at most a few milliseconds, but it would break every plugin that reports a
status. This PR leaves the metrics API untouched, so plugins are not affected.

While rebasing #7897 I also found that its storeStable*() and storeVolatile*() methods stored
everything as config metrics, and its tests compared metrics including their closures, which never
checked the values. Neither applies here anymore.

Tests

• ImplementationOfAgentFinderTest: plugins are found four levels below the plugin directory,
  agent classes of all plugins are searched in one pass, classes of other plugins are ignored.
• StatusCommandTest: a filter for a core agent neither loads the plugins nor asks other agents,
  filters for plugins and for the configuration section, and the error cases.
• AgentCollectionTest: withOnlyAgent().

The complete output of status without a filter is unchanged.

Thanks @daniwe4 for the proposal!