Input Rework

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

Bevy is supposed to be this modular game engine, but its current input solution is everything but that, The current input systems on itself is modular but not in the way most people would want it. I've realised during the development of my commercial game and UI is the worst offender writing a cross platform UI is a massive pain: in mobile games its normal to fire a button click on release (Something not quite builtin to bevy), and there currently isn't a good builtin way to do GamePads in UI that doesn't require a lot of repetitive code

## What solution would you like?

A new layer on top of the current input system (and a small change to the Interaction enum). These are just some of my ideas I'm very open to discussion as I want the best solution. Also I would like to know what would be more appreciated: a proof of concept pr or proof of concept library.

Resources:
- `Focused(Entity)`: The (ui) entity that is currently in focus
Components:
- GamePadEnabledButton(...) Let a button of a gamepad interact with the buttons `Interaction` as long as this entity is the focused entity or the child of the focused entity
- FocusLayout
```rust
FocusLayout{
next:Option,
previous:Option,
left:Option,
right:Option,
up:Option,
down:Option,
}
```
A component that instructs where focus will go to next (upon pressing a directional key)

In addition the `Interaction` enum will need cases for `Outline/Focus` for when an entity is in focus and some sort `Released/Confirmed` for when the button is released.

Also I don't think it would be crazy to add a full input manager above the input system, but that might be out of scope

Start by reviewing Bevy's current input systems and UI Interaction enum, then compare them with the proposed Focused resource, GamePadEnabledButton and FocusLayout components. The scope is not settled: first establish whether this should be a proof-of-concept PR or library and agree on focus, directional navigation, and release behavior. Done requires an accepted design and a defined implementation scope.

Written by the indexing model from the issue text.