feat: add GitHubProductionRelease workflow for promoting to production

[hoegertn]

Summary

Adds a reusable GitHubProductionRelease component that generates a manual Production Release workflow, modelled on the hand-written production-release.yml used in radball-digital. It is triggered via workflow_dispatch and:

1. Checks out full history (default GITHUB_TOKEN)
2. Fast-forward merges the project's default release branch into a selected production branch
3. Pushes the production branch

This keeps a production promotion a deliberate, auditable action separate from merging to the default branch.

Behaviour

• Source branch is derived automatically from the project's default release branch — not configurable on the construct. MonorepoProject now exposes a defaultReleaseBranch field so the construct picks it up.
• Target is selectable. productionBranches (default ['production']) lists the candidate targets. With more than one, the workflow renders a target choice input so the operator picks at dispatch time — e.g. one Amplify app tracking production and another tracking production2.
• Merge is always --ff-only; the chosen target travels through a TARGET_BRANCH env var (no shell injection from the dispatch input).

Wiring

Opt-in on MonorepoProject via productionRelease: true (+ optional productionReleaseOptions). Existing projects are unchanged until they opt in.

new MonorepoProject({
  defaultReleaseBranch: 'main',
  productionRelease: true,
  productionReleaseOptions: { productionBranches: ['production', 'production2'] },
});

Tests

test/production-release.test.ts — opt-in default-off, default main→production, multi-target choice input, default-release-branch-as-source, and the GitHub-required guard. Full projen build (jsii compile + eslint + jest) passes.