(I003) update usage of variable_filter

[syntron]

update handling of variable_filter

• use public function ModelicaSystemABC.set_variable_filter() to define

• process it in ModelicaSystemABC._process_override_data() as command line argument

• use new processing for variable_filter

• add unittest test_variable_filter()

[cbu-hw]

I'm not sure what's going on with these masses of huuge PRs (who will review that in finite time?!), if that is an AI running wild or not. On the off chance-that this is some kind of structured stacked-feature way of developing features, have you heard that github now formally supports "stacked pull requests"? https://github.github.com/gh-stack/
Maybe that's something that might be useful for you?

[syntron]

I'm not sure what's going on with these masses of huuge PRs (who will review that in finite time?!), if that is an AI running wild or not. On the off chance-that this is some kind of structured stacked-feature way of developing features, have you heard that github now formally supports "stacked pull requests"? https://github.github.com/gh-stack/ Maybe that's something that might be useful for you?

I'm the AI running wild ;-) at the end this set of patches was created over a long time. It started quite small (some discussion in PR #404; development started mid of 2025). The small changes accumulated (and new ideas were added) but I never had it down to the point as commit ready steps. However, to get it into OMPython I had to scale it down to handleable pices. But - due to additional requests / discussions - there are new items added at the top ...

The original code is spitted into even smaller commits which show some of the try-and-error development; I reworked it (see: https://github.com/syntron/OMPython/tree/syntron_RFC) and asked if these small commits could be merged into 'steps' of single commit PRs to keep the rebase work low.

The stacked PR idea sounds fine - but is is at the moment not rolled out :-(