Module system improvements

[fisharebest]

• Move modules from /modules_v?/* to /data/modules/*. Since webtrees can write to this folder, we will be able to install and upgrade modules from the control panel.
• Modules to be installed by uploading a .ZIP file, or providing the URL of a ZIP file.
• Allow modules to disable/replace core modules.
• Allow modules to add config options to the tree-preferences page.
• Allow modules to add config options to the user-preferences page.

[ric2016]

It would be useful to also have the option to install multiple modules at once - There may be dependencies between custom modules which require them to remain synchronized.

(it is not always possible to combine those separate modules into a single module as long as a custom module can only implement a single tab, chart etc.)

[fisharebest]

as a custom module can only implement a single tab, chart etc.

Perhaps a better solution is to allow modules to provide multiple tabs, charts, etc.?

[ric2016]

Perhaps a better solution is to allow modules to provide multiple tabs, charts, etc.?

That would be useful in general anyway.

For modules providing a lot of (partly unrelated) functionality, it may still be better to keep them separated.

[ric2016]

• Improvement:

Support additional module meta information (version ranges, changelog) so that compatibility of a module can be determined prior to a) module upgrade b) webtrees upgrade, and so that the webtree admin may decide the urgency of the module upgrade (via the provided changelog).

An example of this meta information handling is currently implemented in Vesta Common.

(see also https://github.com/fisharebest/webtrees/issues/3543#issuecomment-799695350)

[ric2016]

(some of the following has been mentioned above - to summarize:)

• Improvement: Allow modules to provide multiple components, such as charts, tabs etc.,
• Improvement: Provide an option to enable/disable specific functionality (a chart, a tab ...) without affecting the rest of the module (currently this is only possible indirectly by setting the respective access levels to 'hide from everyone', but this has do be done separately for each tree)

Depending on the solution of the first issue, the second issue may not have to be addressed separately. E.g. if we introduce something like a 'container module', which contains a number of sub-modules that are treated just like separate modules within webtrees, but are installed via a single folder. That may in fact the easiest way to implement all of this.