Add a PEP 503-named entry point for project-name normalization #25

Describe the feature

Add a PEP 503-named entry point for project-name normalization, so callers normalizing a package name don't have to reach for extras.Normalize.

Why

PEP 503 project-name normalization and PEP 685 extra-name normalization are the same transformation — lowercase, then collapse any run of -, _, . into a single -. extras.Normalize already implements it, and its own doc comment says it mirrors pypa/packaging's canonicalize_name for PEP 503/685 both.

So the behavior is right and there is no duplication to remove. The problem is purely discoverability and call-site legibility: go-pyresolver's index.NewPackageName currently calls extras.Normalize to normalize a project name, which reads like a bug at the call site even though it is correct. The alternative — a second copy of the algorithm in go-pyresolver — would be worse, since two copies can drift.

Suggested shape

Either is fine; the second is probably cleaner:

1. A packagename package with Normalize(string) string, and extras.Normalize delegating to it (or vice versa) so there is exactly one implementation.
2. Keep one implementation in an internal package, with extras.Normalize and packagename.Normalize as thin named wrappers, each documenting its PEP.

Whichever way, one implementation. The current function is on a per-dependency, per-extra hot path during resolution and is deliberately regex-free, so keep that property.

Testing notes

The existing extras tests cover the transformation. A new entry point needs only enough to prove delegation, plus the PEP 503 examples from pypa/packaging's own test suite for the project-name framing.

Additional notes

• Once this lands, update go-pyresolver's index/name.go to call the new entry point and drop the apologetic comment pointing here.
• Not urgent and not blocking: today's arrangement is correct, just awkward to read.