fix(build): name canaries after the release, not after a prerelease

[armando-navarro]

Fixes #3766

These changes take us back to the release candidate pattern this repo used up until #3674, after which @angular/fire@next started resolving to a canary build instead of the release candidate.

Details

• The root package.json version field returns to 21.0.0, so a canary published from main is named 21.0.0-canary.<sha>, which ranks below every 21.0.0-rc.N.
  • Release candidates are published from their own git tag, which is where tools/build.sh takes a tagged release's version from.
  • This is how releases through v20 were cut.
• tools/build.sh also drops any prerelease part when naming a canary, and says so in the build log, so a prerelease written into that field again cannot produce a canary that outranks it.
• The comment and log line in src/schematics/common.ts no longer say a prerelease range matches canary builds, since it stops being true with this PR.
• The sample's tarball path follows the version field, becoming angular-fire-21.0.0.tgz.
• A second commit regenerates sample/package-lock.json, which still named the 21.0.0-rc.0 tarball, two releases behind its own package.json.

Verification

Every naming path was run against the real script.

• With the field at 21.0.0, a merge to main and a pull request build:
  • both produce 21.0.0-canary.95b3de1 on the canary tag
  • the tag 21.0.0-rc.2 publishes 21.0.0-rc.2 on next
  • the tag 21.0.0 publishes 21.0.0 on latest.
• With a prerelease left in the field, the build still succeeds and names the canary 21.0.0-canary.95b3de1, logging why.
• 21.0.0-canary.95b3de1 is selected by none of ^21.0.0-rc.1, ~21.0.0-rc.1, ^21.0.0-rc.2, ^21.0.0 or 21.x, and ranks below 21.0.0-rc.1.
• npm run test:node after a full build: 331 specs, 0 failures.
• The build produces angular-fire-21.0.0.tgz, and npm ci in sample/ succeeds against the regenerated lockfile, where it previously failed on the mismatch.

[tyler-reitz]

Approving. Every naming path reproduces: I ran this branch's build.sh with npm version/npm run build stubbed, and a merge to main gives 21.0.0-canary.95b3de1 on canary, tag 21.0.0-rc.2 gives next, tag 21.0.0 gives latest, and a prerelease left in the version field still yields 21.0.0-canary.95b3de1 with the new log line.

One thing for the release notes rather than for this PR. The 25 canaries already on npm outrank every future rc of 21.0.0, not just rc.1. Their prerelease parses as ["rc", "1-canary", "95b3de1"], and the alphanumeric 1-canary ranks above the numeric 2, so ^21.0.0-rc.2 and ~21.0.0-rc.2 both still resolve to 21.0.0-rc.1-canary.95b3de1. #3766's scope note is accurate, but it reads as though rc.2 clears this. It will not; deprecating the 25 would.