Regression: clicks are missed in reactive rendering mode

[aevyrie]

When using bevy with reactive winit rendering to reduce power draw, bevy_egui will ignore button presses that wake the event loop.

This was fixed in #226, but that change seems to have been crushed or reverted.

Bug repro:

1. Set bevy's win plugin to use low power mode
2. Launch an egui example with a button
3. Move mouse over the button
4. Wait for a few seconds
5. Click the button, nothing will happen

[aevyrie]

I am partially incorrect. The fix was not squashed, it is still present, however we are seeing the issue.

[aevyrie]

Here is a hacky system we are using downstream to fix the issue:

/// This was added to fix button clicks not responding if the mouse click is what wakes the event
/// loop. A [fix was made upstream](https://github.com/mvlabat/bevy_egui/pull/226), but the issue
/// persists. Keeping this here until we better understand a fix.
///
/// Force egui to treat every frame as if its running at the target framerate. This is necessary
/// because due to a varied mix of bugs and unintended behaviors, when a mouse button press happens
/// and wakes up the app, the reported delta time for this frame will be the full wait time
/// configured for Reactive mode, and on the frame after when the mouse button is released, the
/// reported delta time will be the time the last frame spent waiting, until it was woken up midway
/// through.
///
/// This misreporting can cause egui to think more time passed between button presses than how much
/// time actually passed, leading egui to discard the click.
///
/// Forcing egui to not look at bevy reported time values circumvents this issue.
fn bevy_egui_fix(
    mut contexts: Query<&mut bevy_egui::EguiInput>,
    frame_limit: Res<bevy_framepace::FrametimeLimit>,
) {
    let frame_limit = frame_limit
        .0
        .try_lock()
        .map(|duration| duration.as_secs_f32())
        .unwrap_or(1.0 / 60.0);

    for mut input in &mut contexts {
        input.0.time = None;
        input.0.predicted_dt = frame_limit;
    }
}

Note that we use bevy_framepace, so we use the computed frame limit as a more accurate target frame rate than assuming 60 Hz.