Add a site health check for global table schemas

[johnbillion]

The intention of the DO_NOT_UPGRADE_GLOBAL_TABLES constant is to allow a site owner to defer potentially expensive schema or value updates to tables that are considered global to a network (although this doesn't only affect Multisite networks).

Quoting ​the developer.wordpress.org page on this topic:

Since an ALTER, or an unbounded DELETE or UPDATE, can take a long time to complete, large sites usually want to avoid these being run as part of the upgrade so they can handle it themselves.

During recent discussion on #21022 it was discovered that wordpress.org has never applied the wp_users table schema upgrade made in WordPress 4.4 over nine years ago. This is definitely a situation we want to avoid happening in the future as it risks delaying future enhancements both to schemas themselves and to data stored in the database.

The DO_NOT_UPGRADE_GLOBAL_TABLES constant should facilitate deferring a schema change rather than never making it, so let's introduce a site health check which flags outdated table schemas as critical issues.

Some schema changes can be found by looking for calls to wp_should_upgrade_global_tables() but others will need to be found by looking at the svn/git history of the wp_get_db_schema() function.

[swissspidy]

Related: ​https://github.com/wp-cli/ideas/issues/46