Replace chardet with charset-normalizer as preferred encoding detection

[imsurat]

Summary

• charset-normalizer is now the preferred encoding detection library (same .detect() API as chardet)
• chardet is supported as a fallback if charset-normalizer is not installed
• If neither is available, falls back to utf-8 with a helpful warning message
• chardet available as an optional extra (pip install diff-cover[chardet])

Motivation

• chardet 7.0 relicensing dispute (chardet/chardet#327) creates legal uncertainty for downstream users
• charset-normalizer is MIT-licensed, actively maintained, and already the preferred library for requests
• This makes chardet fully optional while maintaining the same encoding detection capability

Changes

• diff_cover/snippets.py: Try charset_normalizer.detect() first, fall back to chardet.detect(), then utf-8 with warning
• pyproject.toml: charset-normalizer >= 2.0.0 as main dependency, chardet as optional extra
• poetry.lock: Updated to reflect dependency change

Known behavior difference

test_latin_one_undeclared will fail when running with charset-normalizer instead of chardet. This is because charset-normalizer detects the short latin-1 test string as CP932 (Japanese) rather than latin-1 — a known limitation with very short ambiguous text samples. chardet happens to get this one right.

This is exactly the edge case mentioned in #313 where a --src-encoding CLI option would provide a better solution than guessing. The test could be made conditional on which library is installed, or the CLI encoding option could be added as a follow-up.

For the vast majority of real source files (which are much longer than the 32-byte test fixture), both libraries produce identical results.

Addresses

Closes #313

Test plan

• Verified charset_normalizer.detect() returns same shape as chardet.detect()
• 244/245 tests pass (1 known difference on short ambiguous latin-1 text)
• Linter (ruff) passes
• pyproject.toml valid (no duplicate sections)