Feature proposal: configure the numeric part of the wheel build tag #1390

Allow callers to set the numeric part of the wheel build tag from an external
rebuild counter. Currently, Fromager derives it from the combined variant and
package changelog lengths. The existing
build_tag_hook
can append suffix segments but cannot supply the numeric part.

Add an optional per-package setting, proposed here as build_number, keyed by
public version (without the local version suffix; local-version keys are
rejected):

build_number:
  "1.2.3": 0
  "2.0": 7

For configured versions:

• Use the nonnegative integer instead of changelog lengths, retaining the
  changelogs as history and preserving suffixes from build_tag_hook.
• Make explicit zero produce a build tag with numeric part 0. A wheel without
  a build tag does not satisfy it.
• Require the complete expected build tag in local and remote cache checks,
  consistently across bootstrap, build and build-sequence. Other build tags
  are cache misses, including those with a higher numeric part. See the related
  cache inconsistency in
  #1360.
• Ensure installation into the build environment uses wheels with the expected
  build tags, including transitive dependencies. Selecting the correct cached
  wheel is insufficient if the installer can still choose a different build tag
  from the local package repository. Installation must fail when a required
  wheel with the expected build tag is unavailable.

Unconfigured versions retain their changelog-derived tags and cache-matching
behavior; pre-built wheels retain their original tags. Configuring any active
explicit build number switches build-environment dependency installation to
a local-only wheel view and reinstalls dependencies, so all required dependency
wheels must be available locally. The caller owns the external rebuild counter
and publication policy.

Related downstream work: RHAI-6526.