feat(problem)!: add a verbose variant of simulate()

[g-braeunlich]

BREAKING CHANGE: The Problem class now has simulate_verbose() as a new required method which has to be implemented by custom Problem classes.

Description

Currently, Problem.simulate() returns a numpy array containing the objective values measuring the performance of the simulated design.
This PR Introduces a new Problem.simulate_verbose() method which returns a SimulationResult (dataclass) object which contains a field objective_values - the return value of the current simulate() method. Specific problem classes can now derive from SimulationResult and add more data.
Problem.simulate() has now a default implementation which calls Problem.simulate_verbose() and returns simulation_result.objective_values. Therefore at least the method simulate() does not receive a breaking change.

Fixes #251

Type of change

Please delete options that are not relevant.

• Documentation only change (no code changed)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• I have run the pre-commit checks with pre-commit run --all-files
• I have run ruff check . and ruff format
• I have run mypy .
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Reviewer Checklist:

• The content of this PR brings value to the community. It is not too specific to a particular use case.
• The tests and checks pass (linting, formatting, type checking). For a new problem, double check the github actions workflow to ensure the problem is being tested.
• The documentation is updated.
• The code is understandable and commented. No large code blocks are left unexplained, no huge file. Can I read and understand the code easily?
• There is no merge conflict.
• The changes are not breaking the existing results (datasets, training curves, etc.). If they do, is there a good reason for it? And is the associated problem version bumped?
• For a new problem, has the dataset been generated with our slurm script so we can re-generate it if needed? (This also ensures that the problem is running on the HPC.)
• For bugfixes, it is a robust fix and not a hacky workaround.

[markfuge]

@g-braeunlich Overall, good first pass. A few questions for me that came up when reviewing:

1. For SimulationResult -- how does the user know, e.g., what the elements of the SimulationResult are? For example, in the multi-objective case in ThermoElastic, how does the user know that in the NDArray for objective_values the first one is structural compliance, the second is thermal compliance, etc.? This was the case before this PR as well, but it just occurred to me now. This would also occur if we started to add stuff to SimulationResult (i.e., how does the user know what the other fields are and how to call them and what they contain?
2. For the docs -- where are these changes documented in the docs? The API page still only mentions simulate and not simulate_verbose for example.
3. Related to the documentation, what should the problem authors add to their documentation pages about the simulate_verbose outputs such that this is discernable/useable by users, and not just buried in the code?

Other than this, things look great!

[g-braeunlich]

@markfuge Thanks for the review. Forgot to link the new method doc to the API. This should be done now. Also added some additional notes to address 3.
Regarding 2.: Atm this is only specified in the docs.
However for another group, I designed an "array class", which wraps a np.ndarray and in contrast to Structured Arrays contains homogeneous data (i.e. floats).
This is how it could look like in action:

@arrayclass
class Arr(ArrayClassBase[np.float64]):
    x: Annotated[float, Index[0]]
    v: Annotated[float, Index[1:]]

a = Arr(np.array([1.0, 2.0, 3.0]))
a.v = [-2.0, -3.0]
np.testing.assert_equal(asarray(a), np.array([1.0, -2.0, -3.0]))

I.e. the underlying data would still be a numpy array, but its elemets could be accessed by identifiers.