Dataclass-like types accept the same values whether or not added as a group

[mauvilsa]

What does this PR do?

A dataclass-like type is added as an argument group when it is the entire type of an
argument (each field becomes its own option, e.g. --data.number), but as a single
typehint argument when it is part of a larger type (e.g. Optional[Data],
list[Data]). The accepted values differed between these two cases. This PR makes them
consistent and fixes several related issues.

Changed

• A dataclass-like type added as a group now accepts a subclass spec with the
  class_path of the type itself, e.g. --data='{"class_path": "Data", "init_args": {...}}', instead of failing with Group 'data' does not accept option 'init_args....'.

Fixed

• A dataclass-like type not added as a group, e.g. Optional[Data], accepted the
  class_path of a subclass, even though subclasses are disabled for these types by
  default. The error now explains how to enable subclass support.
• Signature parameters typed as a non-group dataclass-like type (Optional[Data],
  list[Data], dict[str, Data]) did not accept a path to a sub-config file even with
  sub_configs=True, failing with e.g. No module named 'data'. Also, the path of a
  loaded sub-config was not kept, so save with multifile=True did not write it back
  to its own file.
• Environment variable values for a dataclass-like argument of a subcommand, e.g.
  APP_SUB__DATA='{"p1": 2}', failed with Not a valid subclass of ....

Added

• shtab completion scripts now include the fields of a dataclass-like type that is not
  added as a group.

Documentation updated in the subclasses-disabled and sub-config-files sections; new
tests in test_dataclasses.py, test_paths.py, test_pydantic.py, test_shtab.py and
test_subcommands.py.

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)
• 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?
• 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
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.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 (79d9e3e) to head (693af19).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #952   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           27        27           
  Lines         8252      8305   +53     
=========================================
+ Hits          8252      8305   +53     

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