Fix subgroup

[tcapelle]

This is a standing issue fix: #331

We successfully fixed the issue where subgroups didn't work correctly when parameters were provided through config files. The core problem was that when subgroup parameters were specified in a YAML file, they
couldn't be properly associated with their parent subgroup type.

The Fix

The solution involved two main components:

1. Smart field association for config files:
   - Added code to detect when fields in a config file match fields in a subgroup's default type
   - When matching fields are found, they're automatically associated with the correct subgroup
   - This happens in both dataclass_wrapper.py and parsing.py when processing configs
2. Improved callable type resolution:
   - Enhanced how we handle functions and functools.partial objects in subgroups
   - Added robust resolution of return type annotations to better support nested class definitions
   - Fixed edge cases with string annotations by evaluating them in the correct scope

Before vs After

Before:

# This would fail with "RuntimeError: ['model_a_param'] are not fields of <class 'TrainConfig'>"

model_a_param: test

After:

Both approaches now work equivalently:

CLI args

  simple_parsing.parse(TrainConfig, args=['--model_a_param', 'test'])

Config file

simple_parsing.parse(TrainConfig, config_path='config.yaml')  # where config.yaml contains 'model_a_param: test'

The fix preserves backward compatibility while adding the ability to specify subgroup parameters directly in config files without explicit nesting, making the API more intuitive and consistent.

Mostly authored by Claude Code 3.7

[lebrice]

Hey there @tcapelle , thanks a lot for this!

I'm going to take a look at the code and I'll get back to you. Also, do you mind if I push some changes to your branch?

[tcapelle]

go ahead! thanks for looking at this.