Allow forcing the redeployment of an already-installed extension version

Scope

Allow forcing the redeployment of an extension version that is already installed: re-run the extension handlers for that same version, so that a JAR is re-deployed and the pages of a XAR are re-imported. This covers repairing an extension whose deployed content has been corrupted, modified or partly deleted, and it applies to released extensions as much as to SNAPSHOTs.

Refreshing an installed SNAPSHOT extension with a more recent build while developing – the first use case of the original description, kept in the first comment of this issue – is out of scope here and is handled by XCOMMONS-2748 instead. That is an upgrade rather than a reinstall: with timestamped SNAPSHOT versions the two builds are different versions, so the normal upgrade path applies and the XAR three-way merge keeps working.

Why the existing features do not cover this

• The "Repair" action only rewrites the installed-extensions index. Action.REPAIR calls ExtensionHandler#initialize(), a no-op in AbstractExtensionHandler that XarExtensionHandler does not override, so no content is redeployed – as the UI itself states: extensions.actions.repairXAR.hint=Mark this XAR extension as installed without importing its wiki pages. It is moreover gated on !isValid(namespace), and validity is computed purely from the dependency graph recorded in the index, so a corrupted artifact or a modified or deleted page never marks an extension invalid and never surfaces a Repair button.
• Installing the same id and version again short-circuits in AbstractInstallPlanJob#checkInstalledExtension(), with InstallException("Extension [%s] is already installed on namespace [%s]") when failOnExist is set (the default) and an empty plan plus a warning otherwise. RepairXarJob short-circuits the same way. There is no force or reinstall property on InstallRequest.
• "Compute changes" (DiffXarJob) plus the per-page "Reset" button (XarExtensionScriptService#reset(), Packager#reset()) does reset a page to its packaged state, and does recreate a page that was deleted, but it is one page per click, it requires a full diff job to run first, and there is no bulk operation for all the pages of an extension.
• The remaining workaround is still uninstall followed by install, which deletes the pages and loses any customisation.

Expected behaviour

• An explicit action on an already-installed extension which computes a plan and, once that plan has been validated by the user, re-runs the handlers for the same version. Computing the plan must stay read-only: nothing may be uninstalled, deleted or downloaded before the user has accepted the plan.
• For a XAR, the pages must be merged the way a newly installed page is: ignore the previous version entirely and compare the current (database) version against the next (packaged) version, raising a conflict when the two differ, so that customisations are never silently discarded.