Remove bevy_camera and bevy_ui deps from bevy_input_focus, no feature flag needed

[kfc35]

Objective

• Fixes Regression: bevy_winit now pulls in all of bevy_ui #22305
• Avoid feature flagging

Solution

Taking inspiration from #22309 and building off of #22333, this moves the auto directional navigation to bevy_ui and creates a new system parameter to be used when including automatic navigation.

• directional_navigation.rs of bevy_input_focus still contains the DirectionalNavigation system parameter, but it now only contains logic to do manual navigation. The DirectionalNavigationPlugin is still there, as well as the manual edge map.
• I separated out some code from directional_navigation.rs into two separate files:

1. directional_navigation.rs in bevy_ui which contains the automatic navigation code. There is a new system parameter now, AutoDirectionalNavigator, that wraps the DirectionalNavigation system parameter and does automatic navigation if manual navigation fails.
2. navigator.rs which contains some structs and functions that are used by both the automatic navigation system and the manual navigation code in directional_navigation.rs. This particular refactoring wasn’t particularly necessary, but I feel like the code is little more cleaner for it… I can revert this change if desired

If you think a feature is better for this, then let me know whether #22333 should be considered instead.

If this gets merged, I’ll open up a pull request against release-0.18 to update the release notes, basically saying that users who want to leverage AutoDirectionalNavigation need to use the AutoDirectionalNavigator instead of the existing DirectionalNavigation system param.

Testing

To ensure no regressions, I tested the directional navigation examples and both work as they did before.
cargo run --example directional_navigation - uses the existing DirectionalNavigation system parameter
cargo run --example auto_directional_navigation - uses the new AutoDirectionalNavigator system parameter

[viridia]

I think this is fine for now, but ultimately I think we are going to want auto-navigation to be it's own crate. The reason is because auto-navigation is very useful for diagetic UIs, which means that the navigator will need to be able to work with UI, 2D and 3D entities, possible mixed together on the same window. This will likely require multiple dependencies.

Ultimately all the auto navigator should care about is where on the screen the center of the object is, regardless of what kind of entity it is. The input focus crate and manual navigation is not limited to UI entities, any entity can be focused as long as it has some way to display a highlight.

[mockersf]

no, release notes for the 0.18 should be updated directly on the release-0.18 branch

[mockersf]

This PR is a breaking change so it should not target the 0.18.

We can accept some breaking changes, but I'm not a UI navigation user yet so I don't know if it's OK. @alice-i-cecile ?

[alice-i-cecile]

This PR is a breaking change so it should not target the 0.18.

This is intended as a correction for the 0.18 milestone, to avoid regressing our crate structure. I think a breaking change is warranted here, to avoid fully shipping in a bad state.

Simply moving around code is an acceptable level of breakage during the release-candidate process IMO: imports are easy to fix.

[mockersf]

Simply moving around code is an acceptable level of breakage during the release-candidate process IMO: imports are easy to fix.

Looking at how the example was updated, it's more than just moving code around, some resources and components have been renamed

[jbuehler23]

@mockersf The base changes for this fix is new anyway for 0.18, there would be no users of automatic directional navigation at the moment AFAIK - unless they were working against the dev branch for testing the changes.

IMO these are necessary if we want to land automatic navigation anyway, as my initial implementation broke the modularity and brought in more unnecessary crates/baggage for users which we should avoid.

[viridia]

@mockersf It's either this or revert the feature from the 0.18 milestone entirely.