Sometimes they will still get discovered by python even though their packages have since been uninstalled.
This will also lead to them being reloaded after an uninstall and a subsequent plugin reload.
Marking them as uninstalled and not handing out uninstalled plugins when collecting them solves this.
Since it cannot be reliably determined by the system if a hook is essential for a plugin's functionality or not, it makes more sense to just disable plugins that utilize obsolete hooks then risk running half working plugins.
The new hook allows extending the list of rules for maximum body sizes differing from the default of 100KB and can be used by plugins to allow uploads to them that exceed that file size.
Also extended the plugin manager to detect plugins that implement restart needing hooks (such as the above one) and handling those plugins the same as plugins containing implementations that inherit from octoprint.plugin.core.RestartNeedingPlugin
Plugins may be enabled and disabled during runtime. If they are of types which allow hot loading, this will be done. Otherwise they will be marked as pending and updated after a restart. Same for installation and uninstallation.
Plugins may be loaded, unloaded, activated and deactivated. Errors while trying to load a plugin or initializing an implementation will only result in it staying deactive but registered in the system, allowing it to be further processed e.g. by a plugin manager
Multiple mixins are allowed of course. Allowing multiple implementations lead to too many problems due to plugin names for referring to the APIs of SimpleApiPlugins or the assets of AssetPlugins.
Hence __plugin_implementations__ has been deprecated in favor of __plugin_implementation__. The plugin subsystem will automatically copy the first implementation from __plugin_implementations__ to __plugin_implementation__ and log a deprecation warning.
Adjusted documentation accordingly. Also added docs for helpers.
Detected plugins are now logged in a better readable way and with additional information.
Also marked folder for bundled plugins as bundled - forgot to do that earlier.
This data can still be overwritten from within the Plugin itself by setting the correponding __plugin_xyz__ variables, however it allows getting rid of some repetition if that data has already been specified in setup.py
get_template_vars get split into get_template_vars (for injection additional template variables only) and get_template_configs (for configuring injection of additional template). It's now possible to inject more than one of a given template type from within plugins, and template injection is more intelligent in that if a plugin's templates don't need special configuration and stick to default naming and behaviour, just declaring them inside the templates directory of the plugin will be enough to fire up everything including links to switch to tabs, sidebars etc (the plugin's name being used in such cases for link text).
Plugins may be able to use this method for final setups before the implementations and hooks are evaluated, e.g. for adjusting their offered functionality based on what other plugins are available.
