fix a xc_equal bug

[jeanwsr]

xc_equal produces False for b3lyp vs b3lypg, which are actually identical. Now the function is re-factored to handle alias defined in pyscf.

[MatthewRHermes]

For anyone looking at the red check on this PR: the linux-build (3.8) failure in run 36576168707 is a pre-existing flake, not something this PR introduced.

It's a SIGSEGV (exit 139) in an unrelated test:

Fatal Python error: Segmentation fault
  File ".../scipy/linalg/_decomp.py", line 577 in eigh
  File ".../pyscf/occri/utils.py", line 50 in make_natural_orbitals
  File ".../pyscf/occri/__init__.py", line 279 in make_natural_orbitals
  File ".../pyscf/occri/__init__.py", line 237 in get_jk
  ...
  File ".../pyscf/occri/test/test_regression.py", line 141 in test_convergence_properties

The last scipy release that still supports python 3.8 is scipy 1.10.1. Claude thinks that this is happening because of a defect in the OpenBLAS that ships with scipy 1.10.1. occri/utils.py:50 calls scipy.linalg.eigh(A, b=s). This leads us down to a ?sygvd call in LAPACK.

The segfault reproduces only intermittently, which is consistent with a workspace/threading issue in that older BLAS build; I ran into the same 3.8-only signature at the same _decomp.py:577 in a separate project.

Re-running the 3.8 job should clear it. If someone wants to retire the flake properly: s there is a genuine AO overlap, so the generalized problem is real, but driver='gv' or 'gvx' both do a proper _compute_lwork query first, and a Cholesky-of-S transform to a standard eigenproblem would avoid ?sygvd entirely.

(Investigation carried out with the assistance of Claude Code.)