Support user interaction in `ci_testing`

## What problem does this solve or what need does it fill?

We test examples using Github Actions, but interacting with these examples while they are running is hard. Github Action runners don't have a keyboard and mouse, nor an actual monitor. We want to test the majority of examples, but are limited to examples that do not require any sort of user interaction.

## What solution would you like?

We use `bevy_dev_tools`'s [`ci_testing`] module to specify automated actions that should be run, such as to take a screenshot at a specific frame. These actions are specified by the `CiTestingEvent` enum:

https://github.com/bevyengine/bevy/blob/383314ef627da6654588a704959fc92c67770a52/crates/bevy_dev_tools/src/ci_testing.rs#L42-L47

[`ci_testing`]: https://github.com/bevyengine/bevy/blob/383314ef627da6654588a704959fc92c67770a52/crates/bevy_dev_tools/src/ci_testing.rs

As brought up by @mockersf in [a recent presentation](https://www.youtube.com/watch?v=rnE_nINEs2M), this enum is lacking additional features that would enable greater interaction. Some ideas for additional features, sorted by usefulness, are:

1. [`KeyboardInput`](https://dev-docs.bevyengine.org/bevy/input/keyboard/struct.KeyboardInput.html)
2. [`MouseButtonInput`](https://dev-docs.bevyengine.org/bevy/input/mouse/struct.MouseButtonInput.html)
3. [`GamepadEvent`](https://dev-docs.bevyengine.org/bevy/input/gamepad/enum.GamepadEvent.html)
4. [`TouchInput`](https://dev-docs.bevyengine.org/bevy/input/touch/struct.TouchInput.html)

I propose `KeyboardInput` is added to `CiTestingEvent` so that we can test keyboard interactions in CI. If that is successful, we can re-evaluate whether the other 3 are useful and worth implementing.

## What alternative(s) have you considered?

I think that specifying actions using `ci_testing` is the right direction, thought the list of supported actions is currently very weak. By not implementing this feature, we leave the testing framework underpowered. Testing is one of the best ways to ensure quality, which Rust and Bevy by extension have a reputation for. This is why I believe _not_ implementing user inputs is not an option, though the method used to achieve may vary.

The reason I propose to only support keyboards in the very beginning is because they are very easy to implement, and likely the most useful. The mouse is difficult without moving it, which works on offsets. The gamepad and touch are more obscure are difficult to verify locally without the proper hardware.