Add support for arbitrary pseudopotential families to get_pseudo_orbitals

[elinscott]

Problem

get_pseudo_orbitals resolves pseudopotentials exclusively by md5 lookup against the bundled semicore tables, so any pseudo outside the curated families fails outright with Cannot find pseudopotential <X> with md5 ...

Change

Resolution now proceeds in three steps, and only the last resort is an error:

1. Explicit override — get_pseudo_orbitals gains an overrides mapping, threaded through Wannier90BaseWorkChain.get_builder_from_protocol as pseudo_orbitals_overrides, so a user can state {"Ti": {"pswfcs": ["3S", "3P", "4S", "3D"], "semicores": ["3S", "3P"]}} and bypass all lookup.
2. Table lookup — unchanged behaviour for curated families
3. Read from the UPF — the valence orbitals are read directly from the pseudo's own PP_PSWFC block (via upf-tools): each PP_CHI atomic wave function states its angular momentum and principal quantum number, so the pseudo wave function labels (3S, 5D, ...) are read off rather than guessed. The UPF states its own valence, so there is no aufbau guessing.
   • the principal number is taken from the PP_CHI label, which carries the true atomic n across generators; the PP_CHI n attribute is deliberately not used for it, because some ultrasoft/PAW generators write the pseudo (node-based) principal number there (radial nodes + l + 1), so a node-free 6s/6p/5d projector is labelled n=1/2/3. When a label is empty or non-standard the label is reconstructed from the entry's n/l.
   • fully-relativistic pseudos list one PP_CHI per j channel; these are collapsed to one label per unique (n, l), in file order.
   • derived entries always carry an empty semicores list, and a warning is emitted stating that the orbitals were read from the pseudopotential file and how to override them.

Raises ValueError when the orbitals cannot be read from the file (no parseable PP_PSWFC, no atomic wave functions, an entry whose (n, l) cannot be recovered, or occupations that do not sum to z_valence), with a message telling the user how to provide this information explicitly via overrides.

Notes

• No behaviour change for any pseudo covered by the bundled tables.
• exclude_semicore: True with a UPF-derived entry excludes nothing (because semicores is not read from the file).
• The PP_PSWFC block is read via upf-tools, added as a dependency.
• The summed PP_CHI occupations must agree with z_valence (to numerical noise); a disagreement can mean a valence orbital is missing from PP_PSWFC, so the derivation fails closed to the overrides ValueError.
• A pseudo that carries no atomic wave functions cannot be read this way and gets the ValueError asking for an overrides entry. Notably this includes the entire SG15 family (its UPFs ship an empty PP_PSWFC block), so SG15 still requires a bundled table entry or explicit overrides; deriving from other UPF sections for such pseudos would be a separate follow-up.

Testing

Unit tests in tests/utils/test_pseudo.py cover the derivation (SR, FR j-collapse, label edge cases), the fail-closed paths, and the tier precedence, all on synthetic UPF content.

The derivation was also swept over 1202 real UPFs (PseudoDojo SR+FR, SG15, plus assorted ONCV/ultrasoft/PAW/v1 files): zero wrong label sets — every derivation matched the curated tables or labels predicted independently from PP_INPUTFILE, and the 202 SG15 files fail closed as intended.

[elinscott]

Note: tests expected to fail until #95 is merged