egui_kittest: Allow passing state to the app closure

[lucasmerlin]

The allows us to pass any state to the ui closure. While it is possible to just store state in the closure itself, accessing that state after the harness was created to e.g. read or modify it would require interior mutability. With this change there are new Harness::new_state, Harness::run_state, ... methods that allow passing state on each run.

This builds on top of #5301, which should be merged first

[github-actions]

Preview available at https://egui-pr-preview.github.io/pr/5313-lucas/kittest_state
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

[lucasmerlin]

I just realized that it would also possible to store the generic state in the Harness, making it accessible via a state_mut function (or just making it public on the Harness struct). That would allow us to get rid of all the extra run_state, step_state etc.. methods. Which way would you prefer @emilk?

[emilk]

So we want to have mutable state that is both easily accessible from the ui closure, but that can also be inspected at the end of the test so we can check that the state ended up in the correct, well, state. 🤔

I agree that forcing users to use Rc<RefCell<State>> is too un-ergonomic.

I also agree that the run_state solution proposed in the PR is a bit ugly.

Putting the state in the harness does seem more attractive. We could make Harness generic over state, though that would lead to monomorphization of the whole Harness, probably increasing compile-times. Maybe that's fine, but we could probably work around it with clever use of Any and dynamic-casting, wrapped in ergonomic accessors 🤔 But maybe not worth the effort

[lucasmerlin]

I've updated it so the harness owns the state. I think this is a bit nicer, but I think tests using this are now a bit less readable.
assert_eq!(checked, true) now becomes assert_eq!(*harness.state(), true), which is less obvious and requires the reader to check somewhere else for the meaning of the state.

But still, I think the benefits outweigh the disadvantage here. Also, if you only need to check the state at the end of the test, and not somewhere in between, one could also just reference it in the closure and then drop() the harness and then the state can be accessed again to do a final assert

[lucasmerlin]

Somehow the spell checker suddenly finds some old typos not introduced in this PR 🤔 I've fixed them in #5339