feat: map Conventional Commit types to an increment type

[Kevin-de-Jong]

We only increment on feat and fix; getting a release out of eg. a chore currently requires logic in the workflow which determines the increment type up front. Which also means we end up with empty release notes, as increment-type skips the commit analysis entirely.

This adds an increment mapping, available both as increment-mapping input parameter and as an identical increment-mapping item in the Release configuration file;

increment-mapping:
  chore: PATCH
  docs: PATCH
  perf: MINOR

• both sources are merged per Conventional Commit type on top of the defaults (feat -> MINOR, fix -> PATCH); the input parameter takes precedence, so we can override a single type from a workflow without repeating the full mapping
• supported increment types are MAJOR, MINOR, PATCH and NONE; the largest increment of all commits in the release is applied
• Conventional Commit types are case insensitive, increment types are not; FIX: major works
• the input parameter accepts YAML as well as JSON
• breaking changes remain MAJOR, regardless of the mapping
• scopes are not supported; chore(deps): PATCH is rejected instead of silently never matching
• ignored, with a warning, for calver - every change already results in an increment of the Calendar Version there

Split in two commits; the first one only moves the Release configuration out of changelog.ts into src/configuration.ts, as versioning.ts needs it as well now. getConfiguration takes the default configuration instead of a VersionScheme there, so changelog and versioning no longer depend on each other.

Worth being aware of - the changelog categories are based on the resulting increment type, so a type mapped to PATCH also shows up in any category selecting increment: ["PATCH"] (eg. our own "🐛 Bug Fixes"). Documented in docs/configuration.md; happy to add a types based escape hatch if we want one.

60 tests (15 new), lib/ rebuilt.

🤖 Generated with Claude Code