Concise documentation rewrite and a v4 to v5 migration guide

[mauvilsa]

What does this PR do?

Documentation-only changes, no code behavior is modified.

Rewording of DOCUMENTATION.rst

The entire document has been reworded to be shorter and easier to read, going from 3828 to 3596 lines without removing any section. The changes replace verbose and redundant phrasing with direct statements, and fix the places where the text did not describe what the code actually does.

New migration guide

A new sphinx/migrate_v5.rst page (linked from the index as migrate-v5) explains how to move from v4 to v5. It recommends upgrading to the latest v4, running with JSONARGPARSE_DEPRECATION_WARNINGS=all and fixing every warning before upgrading. It starts with a summary of the breaking changes that need attention, in particular the ones that give no warning or only warn with all, and then covers, with before/after examples and tables:

• CLI to auto_cli, return_parser and implicit component discovery.
• Renamed parser methods and renamed keyword parameters.
• Namespace changes: parse_as_dict, with_meta/default_meta and the removed utility functions.
• dump, save and validate parameter renames.
• Paths: legacy action classes, the immutable Path API and enable_path.
• Removed legacy action classes ActionEnum, ActionOperators and ActionJsonnetExtVars.
• Settings functions replaced by set_parsing_settings.
• The new defaults for subclass specs in types that accept any value and for denied import paths, including how to get the v5 behavior already in v4.
• Removal of LoggerProperty, error_handler and usage_and_exit_error_handler, and the use of exit_on_error instead.
• Miscellaneous removals, the ruyaml to ruamel extra rename and the fact that internal module paths can no longer be imported.

Packaging

• New yaml extra, included in all, so that the yaml requirement can be installed explicitly, as the migration guide instructs for v5.
• dev now includes all, so that a development install has every optional feature available.
• Extras reordered to be consistent.

Before submitting

• Did you read the contributing guideline?
• If you used a coding agent, did you fully understand and validate all generated code and ensure it follows the contributing guidelines?
• Did you update the documentation? (readme and public docstrings)
• [n/a] Did you write unit tests such that there is 100% coverage on related code? (required for bug fixes and new features)
• Did you verify that new and existing tests pass locally?
• [n/a] If this is a bug fix, did you verify that the tests fail without the code fix?
• Did you make sure that all changes preserve backward compatibility?
• Did you update the CHANGELOG including a pull request link? (not for typos, docs, test updates, or minor internal changes/refactors)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (d950f3f) to head (723516b).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #964   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           28        28           
  Lines         9209      9209           
=========================================
  Hits          9209      9209           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.