modulemanager: Add plugin load filter that reads module metadata from source Metadata in modules is added using lines formatted as: --% key: value Where key is a valid identifier string, and value is also a string (leading and trailing whitespace are trimmed during parsing). The initial supported keys are: --% requires_core_features: feature1, feature2, ... --% conflicts_core_features: feature1, feature2. ... These 'features' map to features reported by the new core.features module. A benefit of this load-time metadata approach compared to e.g. something like module:requires()/module:conflicts() is that we can continue to look in module search paths for a suitable module. Aborting an already-loaded module due to a version conflict would be too late.

modulemanager, moduleapi: Switch to new pluginloader interface

core.features: New module to track and expose the features supported by Prosody A "feature" is a simple string, and it's expected that we will add to (and maybe remove from) this list over the course of time.

util.pluginloader: Support for a per-file load filter Load filters can choose to block the loading of certain files, and optionally return some metadata about the loaded file.

util.pluginloader: Support for multiple pluginloader instances, and options

mod_pep: Clarify purpose of fallback service Extra-extra obvious that no interaction with this should lead to persisted changes

mod_pep: Correct initialization of fallback service I'm not sure what went wrong here, copy-paste mistake? Doesn't matter as long as nobody can create nodes on this service.

core.loggingmanager: Add FIXME about supporting console logging to stderr Currently it is hard codded to be a specialized stdout logger, which should be fixed one day.

man/prosodyctl: Complete list of 'check' variants Especially 'connectivity' was missing

man/prosodyctl: Clarify description of --root