Docs: reframe shared CONSTANTS as an application-startup contract

[derek73]

The shared module-level CONSTANTS is sound — it's the only channel that reaches parses happening inside code you don't own (helpers, pipelines, third-party libraries using nameparser internally), the same justification logging and locale have. The gotchas all come from mutating it casually. The docs should state that as a contract instead of warning about it:

CONSTANTS is for application-level configuration, set once at startup. For anything scoped — one dataset, one library, one test — pass your own Constants instance.

Changes:

• customize.rst: lead the customization docs with the contract; demote the "Potential Gotcha" section to a consequence of violating it rather than a surprise property of the API
• nameparser/config/__init__.py module docstring: same reframe (it currently teaches the None sentinel first)
• Fold in the three-spelling vocabulary from Add Constants.copy(); deprecate constants=None #260 once Constants.copy() exists

No code changes. Depends on #260 only for the vocabulary mention; the reframe itself is true today.

[derek73]

The constants-contract documentation this issue asked for now exists as the config mapping table on the 2.0 "Migrating from HumanName" page (on the v2/core-foundation branch, PR #288): every CONSTANTS attribute's 2.0 successor in one table, with the flipped non_first_name_prefixes → particles_ambiguous semantics called out in a warning box. Closing as superseded by the 2.0 docs; reopen if a 1.x-specific contract document is still wanted.