HumanName subclasses overriding parsing hooks silently lose their overrides under the 2.0 facade; detect and warn at construction #280

In 2.0, HumanName is reimplemented as a compatibility facade over the new parsing core: the facade delegates parsing to the core engine rather than calling its own (former) parsing methods. A subclass that overrides a parsing hook — parse_full_name, parse_pieces, join_on_conjunctions, pre_process, post_process, or the is_* predicates (is_title, is_prefix, is_suffix, is_conjunction, …) — will still construct and parse without error, but the override is never called.

This is the only planned v1→v2 change that fails silently: every other removal raises or warns, but here the subclass just quietly parses differently. Subclass-override users exist in the wild — the 1.3.0 release note for the __process_initial__ → _process_initial rename assumes exactly this audience.

2.0: at HumanName.__init__, compare the known hook attributes on type(self) against HumanName's own (type(self).parse_pieces is not HumanName.parse_pieces, etc.) and emit a DeprecationWarning — once per subclass, not per instance — naming the overridden methods and stating they will not be called. DeprecationWarning rather than RuntimeWarning: this is a migration matter, not a runtime hazard, and the fix is migrating the customization to the new API (or requesting the missing switch as a feature).

No 1.4 bridge warning for this one, deliberately: the only actionable response to the warning is migrating to the new API, which doesn't exist until 2.0 — a 1.4 warning would be noise its audience cannot act on. (Same fairness rule that keeps the shared-CONSTANTS deprecation in 2.0.)