Avoid deprecated Sphinx autodoc options mapping

[utkarshalpha]

Summary

• read non-dict autodoc options through their instance attributes instead of the deprecated mapping interface
• retain direct dictionary handling for existing callers
• add a regression object whose mapping methods raise deprecation warnings, matching Sphinx 10 behavior

Fixes #679.

Tests

• pytest -q (315 passed, 2 xfailed)
• pytest numpydoc/tests/test_numpydoc.py -q (19 passed)
• ruff check numpydoc/numpydoc.py numpydoc/tests/test_numpydoc.py --ignore TRY004
• ruff format --check numpydoc/numpydoc.py numpydoc/tests/test_numpydoc.py
• git diff --check

[larsoner]

Thanks for the PR! Before I look closer -- I think #679 was already fixed by #688, can you check?

[utkarshalpha]

You're right, and thanks for the pointer — I checked and #688 does already fix #679.

I verified against Sphinx 9.0.4 by running the current main branch logic with a real _AutoDocumenterOptions instance:

from sphinx.ext.autodoc._directive_options import _AutoDocumenterOptions as O
o = O.from_directive_options({"exclude-members": "upper"})

_AutoDocumenterOptions does expose from_directive_options, so the elif hasattr(options, "from_directive_options") branch added in #688 is the one taken, and it uses vars(options). Zero RemovedInSphinx11Warning are emitted. The deprecated cfg.update(options or {}) path in the else branch is never reached for Sphinx's own options object.

So the bug in #679 is genuinely gone, and my PR isn't fixing anything real. The only thing left is cosmetic: since vars() covers every non-dict case, the hasattr check and the try/except TypeError fallback below it are now dead code, and the three branches collapse to two. (The isinstance(options, dict) branch does need to stay — vars() raises TypeError on a plain dict.)

That's cleanup, not a fix, so I'm happy either way: I can trim this PR down to just that simplification plus the regression test, or simply close it if you'd rather not churn that function. Let me know which you prefer, and #679 can probably be closed as resolved by #688 regardless.