refactor(crates): publish library as evt3, CLI as evt3-cli, and make the project findable

[muthmann]

Makes the project installable and findable. It was effectively invisible: the
GitHub repo had no description and no topics, the CLI was not on crates.io at
all, evt3-core was stuck at 0.2.0 while the workspace moved to 0.3.0, and the
PyPI page was a stub that told visitors to build from source.

Breaking change

The decoder library is published as evt3 instead of evt3-core:

- evt3-core = "0.2"
+ evt3 = "0.3"

- use evt3_core::Evt3Decoder;
+ use evt3::Evt3Decoder;

Source directories are unchanged. The CLI is published as evt3-cli and still
installs a binary named evt3, so command-line usage does not change.

The short name went to the library, not the CLI. A binary-only crate has no lib
target, so cargo add evt3 succeeds silently and only fails later at compile
time with E0433 — whose help text then suggests the command the user already
ran. Registry names cannot be reassigned, so this had to be settled before the
first publish. Rationale is recorded in ADR 0005.

Result:

Command	Gets you
cargo add evt3	the Rust library
cargo install evt3-cli	the CLI (binary evt3)
pip install evt3	the Python package

evt3 now means the library on both registries.

Publishing was also broken

Two things would have failed cargo publish regardless of naming:

• evt3-cli declared six crates.io keywords; the registry permits five.
• Path dependencies carried no version, which crates.io rejects. The internal
  dependency is now declared once in [workspace.dependencies].

The release workflow never touched crates.io, which is why the library went
stale. A publish-crates job now publishes evt3, waits for the index, then
publishes evt3-cli — the order matters, since the CLI cannot be packaged
until the library is in the index. Both steps treat an already-published
version as success, so re-running a tag recovers.

Discoverability

The root README led with "EVT3 Decoder" and never mentioned Metavision, DVS,
neuromorphic, or event-based vision. Rewritten around the terms people search,
with crates.io/docs.rs/pyversions badges.

evt3-python/README.md — the PyPI landing page — was a 1587-character stub
recommending a source build. Replaced with a full page using absolute links,
since PyPI does not render relative ones.

Repository description, homepage, and 20 topics were set directly on GitHub and
are already live.

Verification

Check	Result
cargo fmt --check, clippy -D warnings (± hdf5)	clean
Rust lib tests	28 pass / 30 with hdf5
Integration tests	8 pass / 16 with hdf5, incl. real-file HDF5
Doctests	2 pass
MSRV cargo check -p evt3-python on Rust 1.83	pass
Python 3.9 / 3.13 / 3.14t free-threaded	pass
CLI vs C++ reference	identical MD5, 1.64x faster
cargo publish -p evt3 --dry-run	pass
Markdown links and anchors, repo-wide	all resolve
Every documented cargo … -p <pkg> command	executed, all work

Verified on macOS/arm64 only; Ubuntu, Windows, and Python 3.10–3.12 are covered
by CI on this PR.

Not included

The version bump belongs in the release commit, per RELEASING.md. After merge,
workspace.package.version, workspace.dependencies.evt3.version, and
evt3-python/pyproject.toml go to 0.4.0, ## [Unreleased] becomes
## [0.4.0] - <date>, and the tag triggers the publish.