ci: add release-please for automated per-package versioning

[kewde]

Summary

• Add release-please-config.json + .release-please-manifest.json + .github/workflows/release-please.yml for automated version bumping, changelog generation, and GitHub Releases per package
• Manifest mode, 6 independent components: the 5 xknx-* libraries (packages/*) plus knx-gui (apps/knx-gui), each release-type: python (bumps [project].version in its pyproject.toml)
• separate-pull-requests: true — each package gets its own release PR and its own tag/release (<component>-v<version>), independent timing
• bump-minor-pre-major: true — a breaking change (feat!:/fix(scope)!:) on a 0.x package stays in the 0.x range instead of jumping straight to 1.0.0
• Manifest baseline is 0.0.0 for every component — none of them have actually shipped a release yet (see docs: mark all changelogs unreleased, add changelog-format CI check #3), so the first real release lands wherever the conventional commits merged after bootstrap-sha add up to
• Uses the default GITHUB_TOKEN (no new secrets needed) — the one tradeoff is release-please's own generated PRs won't trigger other push/pull_request workflows (GitHub's anti-recursion rule), but the repo ruleset doesn't require status checks to merge, so this doesn't block anything

Depends on

• PR-title-lint (ci: lint PR titles against Conventional Commits #4, merged) — release-please's changelog lines come from squash-merge commit messages, which default to the PR title, so titles need to follow Conventional Commits for this to produce anything
• Squash-only merge ruleset (already applied) — keeps each merged PR to exactly one commit

Test plan

• Both JSON config files validate
• Confirm the workflow runs on merge and opens release PRs as expected once a feat:/fix: PR lands for a given package