Reset update numbers from 8xxx to 1xxx

[quicksketch]

This is a followup to #117 and #3 (though it can be done independently of either). We need to reset the version numbering on updates from being 8xxx updates to go back to 1xxx updates, so future versions of Backdrop can follow the normal numbering conventions without needing to have 9xxx and 10xxx updates in Backdrop 2 and 3.

[quicksketch]

I think in general this can be done fairly simply in update.inc. Drupal/Backdrop doesn't actually have any real connection between update numbers and the software version, it's just convention, so we just need to reset the count back to 1000. I think our checking could be something like this:

• If a module's schema version is >= 7000, run all updates up to 7999, then start counting at 1000 and append all updates as if 1000 were the next number. If there are no updates <7000, leave the schema number as-is in the 7xxx's.
• If updates exist that are >= 7000 but the module schema is < 7000, ignore the updates.
• If a module's schema version is >= 8000 (like all core modules with updates currently), subtract 1000 from the number and append all later updates to be run. e.g. system_update_1011 would run next if system.module's schema is currently 8010.
• We immediately rename all the updates from 8xxx to 1xxx.

This makes it so that "Backdrop compatible" modules wouldn't need to fork in order to support Backdrop updates, since 7xxx numbered updates would not be run once the schema has been reset to 1000. Backdrop updates would be numbered 1xxx, D7 updates would be 7xxx. It also makes it so modules that allow upgrading from previous versions other than the latest release would be able to leave their updates in place, hopefully without any kind of Backdrop-specific modifications.

A similar treatment would be included for hook_update_last_removed(), where a "last removed" update could be 7105, and a 1000 update would be considered as a valid next number, but if the schema was only at 7104, an error would be thrown.

Basically, all of this is to say, we'd consider 1000 to be the next number after 7999. Updates from 0 to 6999 run normally and in order just like they do today. And by the time we reach Backdrop 7.0, we'll need to remove these checks.

We'll see how complicated this all is in practice shortly. I'm looking for feedback on this general idea though, if anyone has any better ideas.

[quicksketch]

I've filed a pull request at backdrop/backdrop#220 that accomplishes this functionality. It seems to work well in my manual testing, but we'll need comprehensive automated testing to ensure this rather confusing functionality works as expected.

[quicksketch]

An update to the PR now includes full testing, including:

• Updating from 7xxx to 1xxx. Unrun 7xxx updates will be executed if they exist in the Backdrop versions of the module.
• Updating from 8xxx to 1xxx (for the existing updates that have been renamed).
• Testing hook_update_last_removed() as a 7xxx value, the next updates are 1xxx (assuming the 7xxx update requirement is met).
• Modules with 1xxx (and all the way up to 6xxx) schemas will not re-run any 7xxx or 8xxx updates, since those are considered for compatibility.

The PR of course also actually renames all the update functions, and documentation where needed (in hook_update_N() and hook_update_last_removed()).

[quicksketch]

I've merged in backdrop/backdrop#220. We've got a few outstanding PRs that have update numbers but I think they already need work at this point anyway. They'll need to updated to change their update numbers.

[quicksketch]

Hmm, now when testing other PRs (such as #173), I found that if you set your schema version ahead (such as testing an update, then rolling back the code) that it may cause all updates to be re-run from 1000 if the current schema is missing. That's no good. I've submitted a followup PR at backdrop/backdrop#269 to resolve this. We'll let tests run to make sure this new approach works.

[quicksketch]

The new comparison approach now looks like it resolves this problem with running all the updates over again if the expected schema is missing. Now it uses comparisons directly on the update numbers, so re-running existing updates should be impossible again. Merged in backdrop/backdrop#269.