feat: support configuring the initial prerelease number

[ayloncarrijo]

Allow configuring the starting number for the first generated prerelease (e.g. 1.0.0-alpha.1 instead of 1.0.0-alpha), with subsequent bumps continuing from that value.

Fixes #2467

Problem

Today, the only way to get a numbered first prerelease is to work around it by manually setting "prerelease-type": "alpha.1" (or similar). This is a hack:

• It abuses prerelease-type, which is meant to hold a simple identifier like alpha or beta, not a pre-baked version fragment.
• It's not documented, so users have to reverse-engineer the bump logic to find this trick.

Solution

Add a new prerelease-initial-number config option (CLI flag, manifest/config JSON, and JSON schema) that lets users explicitly set the starting number for the first prerelease:

• Not set: unchanged, first prerelease is 1.0.0-alpha.
• prerelease-initial-number: 1: first prerelease is 1.0.0-alpha.1.
• prerelease-initial-number: 0: first prerelease is 1.0.0-alpha.0, continuing as alpha.1, alpha.2, ...

Only the "first transition into a prerelease" logic in PrereleaseVersioningStrategy changes. Subsequent bumps already increment any numeric suffix via existing logic.