[FIXED JENKINS-24380] Use build numbers as IDs

[JENKINS-24380](https://issues.jenkins-ci.org/browse/JENKINS-24380)

The idea is that the directory of the build is named after its number, which greatly simplifies a lot of lazy-loading code, as well as making “out-of-order builds” an impossibility, and fixes some miscellaneous issues with rapidly created builds and timezone changes.

For newly created builds, the `number` is implied by the directory name, the `id` is also computed as the stringified `number`, and the `timestamp` is just a plain old field stored in `build.xml`.

For historical records there is a one-time migration step (so that runtime lookup code is not made more complicated or slow again). The `number` is stripped out of the XML and used to rename the build directory. For compatibility with existing references from other code, the `id` is captured from the old directory name before it is renamed, and stored as a persistent field in `build.xml`; the `timestamp` is likewise parsed out of that `id` and stored. `RunMap` also effectively supplies `AbstractLazyLoadRunMap` with a map from historical IDs to numbers so it can correctly service lookups by ID; this mapping is created in a single file (per job) during the migration.

- [x] provide some kind of reverse migration tool

[JENKINS-24376](https://issues.jenkins-ci.org/browse/JENKINS-24376) notes five plugins which seem to make assumptions about the current directory layout and ID format (`yyyy-MM-dd_HH-mm-ss`, `ID_FORMATTER`, `getIDFormatter`) and which would need to be updated to match this:

- [x] `ftppublisher` (seems OK, `useTimestamps` is an option, but should not really matter what the `Run.id` is)
- [x] `jobConfigHistory` (looks to have been a false positive)
- [x] `support-core`
- [x] `build-publisher`
- [x] `disk-usage`

Additionally some other plugins do unusual things when creating `Run`s so these ought to be retested against the patched core:

- [x] `matrix-project`
- [x] `external-monitor-job`