Rename "purge" to "uninstall", differentiate between "install" and "enable"

[EXreaction]

I am not sure how that would work correctly with both having differing left/right id trees

[imkingdavid]

Could we add a 0-default "extension_id" field to the modules table that could be used to associate extensions with their added modules? It would be assigned in the background when the module.add migration is run, and then it would be a simple action during the disable process to grab all of the extension's modules by that ID and disable those modules. Of course this wouldn't work retroactively, but that shouldn't matter since we're still in alpha.

[nickvergessen]

Just use the disable option we have on modules table?

We just need to store which modules were added by which extension (an extension might add a core module again to it's own category) and which have been disabled by disabling the extension and should be re-enabled when the extension is re-enabled.

[EXreaction]

The migrator is completely independent from extensions. It does not know or care whether or not the modules being added are from the core or an extension. I'm not sure this is something we should change either.

We could easily add a new permission type to modules, similar to config/acl checks we have now. Authors however would be required to add this to their module auth.