Add optional DFTB+ external backend

[karmachoi]

Summary

• Add optional external DFTB+ backend support for method=dftb energy/gradient calculations.
• Add [dftb] input schema/config keys, DFTB+ HSD/GEN input generation, fixture-backed parsers for detailed.out and results.tag, and runner error handling for missing executables or parameters.
• Wire DFTB+ energy/gradient execution into OpenQP run functions and add ground-state optimization callback support independent of the geomeTRIC branch.
• Add DFTB+ example inputs that document required local sk_path/executable configuration.

DFTB+ availability / skip behavior

• DFTB+ remains optional: parser, schema, writer, and runner tests use fixtures/fake runners and do not require dftb+ or Slater-Koster files.
• If the executable is absent, the runner raises a clear DFTB+ executable not found... error.
• If [dftb] sk_path is unset or missing, the runner raises a clear parameter-directory error.
• Local smoke runs require the user to install DFTB+ and configure sk_path to a compatible parameter directory (for example 3ob/mio files); this branch does not vendor parameters.

Validation

• python3 -m unittest tests.test_dftbplus_backend -v
• python3 -m py_compile pyoqp/oqp/library/dftbplus.py pyoqp/oqp/utils/input_checker.py pyoqp/oqp/library/runfunc.py
• git diff --stat upstream/main...HEAD

Notes

• Scope is intentionally independent of PR feat: add geomeTRIC optimizer backend #133/geomeTRIC; no unmerged geomeTRIC code is required.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7abfefc0b0

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Persist parsed DFTB+ gradients on the normal success path

When method=dftb and a gradient is requested, run_openqp_molecule only assigns mol.grads inside the exception fallback. In the normal path (NumPy + ffi.memmove succeeds), mol.grads is left unchanged, so downstream consumers that read mol.grads (for example Runner.results() in pyoqp/oqp/pyoqp.py) can see None/stale gradients even though DFTB+ returned valid forces. This silently drops gradient results from the Python-facing API for standard installs.

Useful? React with 👍 / 👎.