Version metadata says 1.0.0 while the release line is v0.x — align before wider distribution

## Problem

`pyproject.toml` and `setup.py` both hardcode `version = "1.0.0"`, and have since the repo's first commit. The actual release line is the git tags: `v0.1` → `v0.2.0` → `v0.3.0-rc0.post1`. Every tagged release therefore self-identifies as 1.0.0 — the `v0.2.0` tag's own tree claims 1.0.0, and wheels/distro packages built from any ref get the same constant version.

## Why it matters now

Downstream packages inherit the claim: the current deb/rpm are `flagsparse 1.0.0-1`. Once a real `0.3.0` release fixes the metadata, package managers see it as a **downgrade** from 1.0.0 and refuse the upgrade — the usual escape is a permanent version epoch (`1:0.3.0`), which is ugly and sticks forever.

Checked today: the 1.0.0 artifacts have **not** escaped yet — not on PyPI (neither `flagsparse` nor `flag-sparse`), not in the Nexus apt/yum repositories, and the openKylin packaging push hasn't happened. So this is the last cheap moment to fix it: correct the version now and nothing needs an epoch.

## Proposal

Either of:

1. **Dynamic (preferred):** derive the version from git tags with `setuptools_scm`, as FlagGems does — releases can then never drift from the tag again.
2. **Static:** set `version = "0.2.0"` to match the current release tag, and make the version bump part of the release/tag checklist.

The distro packaging (deb changelog / rpm spec, currently 1.0.0-1) will follow the corrected upstream version in a separate change once this lands.

Read the version declarations in pyproject.toml and setup.py, then compare them with the existing git tags and the proposed setuptools_scm approach. Choose and implement the agreed versioning direction, and verify that packages built from the current release tag report the corrected version rather than 1.0.0.

Written by the indexing model from the issue text.