Support for a less stringly-typed settings api

### 📝 Description of the feature

something copilot prompted me to think about to make things less [stringly-typed](https://www.hanselman.com/blog/stringly-typed-vs-strongly-typed)

```py
drag = report_defs.drag.create(name="cd-mon1")
drag.zones = [
...
]
params_report_defs = session.settings.parameters.output_parameters.report_definitions
param_1 = params_report_defs.create(name="parameter-1")
param_1.report_definition = drag.name # can this just be = drag instead of needing the .name?
```

With this change you can opt-in to catching typos at type time.

### 💡 Steps for implementing the feature

The implementation of `set_state` could check if the argument is settings object and resolve `val = obj.name` (rather than doing it on a duck-typing basis, which carries other risks).

### 🔗 Useful links and references

_No response_

Start by locating the settings API's set_state implementation and the settings object types it accepts. Determine how settings objects are identified and how assignment currently resolves names, then define tests showing that a settings object can be assigned directly while unrelated objects are not resolved by duck typing.

Written by the indexing model from the issue text.