[Concept] Refactor the way tasks access the config

[mranst]

Description

For a few reasons, I've never really loved the way that Swell handles accessing config values from tasks. The way that the config object isn't rendered unless the task itself it run means there's a disconnect in the source code of the task, where you don't necessarily know if you're accessing the right name when you're writing it. The fact that keys in experiment.yaml are being assigned as methods to an object on the fly is a little confusing, and this behavior is buried under a few layers of obfuscation.

So, I've been trying out this concept that is slightly different, where config accesses instead make direct references to questions in question_defaults.py.

self.config.bundles(default=bundles) -> self.config.resolve(qd.bundles, default=bundles)

I like this because I believe it improves the situation I described above. You can now directly see where keys are being defined. It also allows you to see docstrings in the task from an IDE, which can improve readability:

This PR (which is mostly a proof of concept at this point, though it partially works) also does a few other things, including type checking for keys in experiment.yaml from the config, and getting rid of the cli.

There are a few cons to this, including:

• Slightly more complicated language
• The fact that this works by referencing the dataclasses rather than the constructed question objects, which is not quite ideal

So I wanted to put this out there to see if people think this is a worthwhile direction to follow.