Different approach for extension check, refs 4119, 4190

[mwjames]

This PR is made in reference to: #

This PR addresses or contains:

When SetupCheck was introduced as part of #4041 and extended in #4119, #4190 the class became increasingly convoluted with different HTML snippets to create a meaningful error message to the user. The HTML code has been "outsourced" to templates with the definition of what should be generated now being defined by setupcheck.json with the following errors keys:

• ERROR_EXTENSION_LOAD
• ERROR_EXTENSION_INVALID_ACCESS
• ERROR_EXTENSION_REGISTRY
• ERROR_EXTENSION_DEPENDENCY
• ERROR_EXTENSION_DEPENDENCY_MULTIPLE
• ERROR_EXTENSION_INCOMPATIBLE
• ERROR_SCHEMA_INVALID_KEY, and
• MAINTENANCE_MODE

There was also a mix of MW message keys and canonical text making the handling inconsistent in case SMW wasn't loaded those MW keys couldn't be used therefore to avoid cluttering text representations, setupcheck.i18n.json now contains keys and translatable text that is independent of the state of MW and SMW.

#4190 added a check for wfLoadExtension( 'SemanticMediaWiki' ) to detect "doubly" invocation but made it dependent to call ExtensionRegistry::getInstance and left a certain use case uncovered #4190#issuecomment-517948006 making the solution sub-optimal. Instead of relying on ExtensionRegistry we'll register a UncaughtExceptionHandler and inspect those errors we are interested in and make them to look "nice" with some extra context. This also provides us with a means to the fetch additional errors (ERROR_EXTENSION_DEPENDENCY, ERROR_EXTENSION_INCOMPATIBLE etc.) that would otherwise be displayed as "ugly" exception without any context.

This PR includes:

• Tests (unit/integration)
• CI build passed

Examples

[mwjames]

@kghbln As outlined above, the error code (e.g ERROR_SCHEMA_INVALID_KEY) now defines a form in [0] to appear consistently with a similar look and feel (and adding a new error code is easily done by adding a new form definition) while message keys (e.g. smw-setupcheck-invalid-upgrade-key) are defined in [1] to be independent of MW and the Message class. [1] works even if SMW isn't loaded and can be translated in case the need arises.

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/bcb2bd17d70f2b296e54e43028cd7e0b39139a8b/data/template/setupcheck/setupcheck.json
[1] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/bcb2bd17d70f2b296e54e43028cd7e0b39139a8b/i18n/local/setupcheck.i18n.json

[mwjames]

(and adding a new error code is easily done by adding a new form definition)

An upcoming PR will add ERROR_DB_REQUIREMENT_INCOMPATIBLE as I need to increase the minimum requirement for postgres for a different feature.

[mwjames]

As for the mentioned codes, [0] contains a short description for each of them.

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/src/SetupCheck.php#L20-L60

[mwjames]

I started to add some rudimentary information in [0].

[0] https://www.semantic-mediawiki.org/wiki/Help:Setup_check