Replace yanked core2 dependency with no_std_io2

[abraemer]

Disclaimer: I am not very knowledgeable in these parts of the ecosystem and used coding agents for support (GLM 5.1 on company hardware). I worked closely with the agent and reviewed the code. To the best of my knowledge and ability, this PR is clean and makes sense.

Context

All versions of core2 have been yanked from crates.io and its repo is archived. The author suggests "use core directly," but core::io doesn't provide Read/Write/Error/ErrorKind etc. yet, so that's not viable today.

no_std_io2 seems like the most actively maintained drop-in replacement with an identical API. The Read and Write traits are byte-for-byte identical to core2's, and all needed types (Error, ErrorKind, Cursor, Take, Result) are present with the same semantics. The std feature flag works the same way — it re-exports std::io when enabled.

The only differences are additive: Error::new() is generic (accepts any error type, not just &str), ErrorKind has two extra variants (Unsupported, OutOfMemory), Cursor<Vec<u8>> implements Write, and there's a memchr transitive dep.

Summary of changes

Migration was a simple core2 → no_std_io2 rename — no logic changes. All 43 unit tests and 70 doc tests pass. Both std and no_std builds compile cleanly.

Alternatives

There is also no_std_io of which no_std_io2 is the direct fork. no_std_io has slightly more stars (10 vs 8) but the last commit is 3 years old vs. 4 months for no_std_io2. This is why I went with no_std_io2

Close #85

[sile]

LGTM. Thank you.

MEMO

This is a breaking change for no_std users, since the public io types move from core2::io to no_std_io2::io. However, core2 has been yanked across all released versions, so continuing to rely on the current dependency is no longer practical.
In that sense, this looks more like an exceptional migration driven by the dependency situation than a routine API change.
It should not affect std users in the same way, because with the std feature enabled, no_std_io2::io resolves to std::io.
So while this is a compatibility break for no_std, the plan is to treat it as a minor version update rather than a major one when releasing it.