Extension versions should be domain-independent

Extensions may choose to define upgrade steps in their upgrader classes which make changes to the database. The steps are represented as upgrade_N steps, where N is an incrementing integer.

When these steps are run, CiviCRM stores the N value to be sure that the upgrade step isn't run twice, as this may cause database errors or other abnormalities. The N value is stored in the civicrm_settings table under the name org.example.myextension:version.

The problem occurs when running a CiviCRM multisite. CiviCRM stores the setting as domain-specific, so it is possible to have org.example.myextension at version 1101 in Site A and 1103 in Site B. When this is the case, users on Site A will be advised to run the extension upgrades though they have already been run by Site B.

Since a CiviCRM multisite by definition is comprised of a shared code base and a shared database, there should never be a need to run the updates on both Sites A and B. Therefore, I propose that version be tracked in the civicrm_extension table, where a column schema_version already exists for this purpose.