Fix Python documentation generation

[AndreyVMarkelov]

Summary

• keep generated Sphinx field markers intact by separating parameter/type and instance-variable/type fields
• resolve generated class references using the type's declaring namespace, including reserved Python module names such as async_
• convert Stone documentation tags consistently for union fields
• add regressions for cross-namespace types and long Sphinx fields

Root cause

The Python backends embedded complex type roles inside :param field names and wrapped long :ivar markers before their closing colon. Docutils parsed those as malformed field and definition lists. The client backend also formatted foreign types with the route namespace instead of the type's declaring namespace, producing references such as dropbox.team_log.TimeRange and dropbox.files.PollError.

This affects dropbox/dropbox-sdk-python#359, dropbox/dropbox-sdk-python#111, and part of dropbox/dropbox-sdk-python#516.

Impact

Generated Python API documentation uses valid reStructuredText and points to the correct modules. Runtime serialization and client behavior are unchanged.

Using this branch to regenerate the current Dropbox Python SDK reduced both HTML and man-page Sphinx warnings from 398 to 9. The remaining warnings come from handwritten SDK documentation or specification text, not Stone-generated field formatting.

Validation

• pytest -q — 186 passed
• flake8 setup.py example stone test
• pylint --rcfile=.pylintrc setup.py example stone test — 10.00/10
• ./mypy-run.sh — no issues in 59 files
• regenerated the current Dropbox Python SDK and built HTML and man documentation