Prioritization of backlog to add to Metalsmith

[webketje]

These are general and more specific ideas to improve metalsmith that require some further thought/ deeper exploration or a proof of concept. Community feedback highly welcome (also in the form of issues or PRs)

1. Add debugging to the metalsmith builds themselves. This should log when a build starts/ ends, when a plugin starts/ends and how long the build took. The only hurdle to clear here is to make sure that the debug namespace metalsmith (or maybe metalsmith:build?) doesn't clash with existing plugin debug namespaces. In 3.0 the absence of an explicit metalsmith.env('DEBUG') could be defaulted to metalsmith for example when metalsmith.env('NODE_ENV') === 'development'.
2. Check support for loading plugins that are not the default export of a main package file. In JS builds this is not a big problem, but it is currently insufficiently tested whether a plugin fileops/remove will work (in CJS + ESM, using exports or not).
3. Add a separate method metalsmith.entries or metalsmith.files. This would split assigning the files in each metalsmith.run to its own method. Sometimes it is useful to programmatically "set" the set of files that the run works with, for example in unit tests, for partial reloading, or even (in the very distant future) for decoupling the filesystem to move towards a browser-compatible metalsmith distro.
4. Add a keypath utility to metalsmith. I find myself reaching for the likes of lodash.get and lodash.set often while developing plugins, mostly for handling target or metadataKey options. metalsmith.match can easily target files, and I think it would make sense to have a similar metalsmith.key('target.key') method. See also Proposal for metalsmith.get/set() helpers #385 (comment). This would also give way to implementing a CLI command like metalsmith get **/*.html collections.length that would print a {[filepath]: [property value]} result (useful for managing your static site?)