Button data is typically binary, but is treated as if it were continuous

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

Button data often cannot be analogue, it is etiher exactly 0.0 or 1.0 (at least, when returned by `gilrs`). See the investigation in https://github.com/bevyengine/bevy/issues/3246#issuecomment-997977629.

However, we return a `f32`, which is always (at least, when using `gilrs`) either exactly 0.0 or 1.0.

Moreover, we have an often useless `ButtonSettings` struct, which thresholds these returned values in a configurable way, and converts them back into a bool.

Finally, our official example demonstrates that we should be using `Axis` for gamepad triggers, which is semantically wrong.

## What solution would you like?

1. Clearly document that we follow https://w3c.github.io/gamepad/#dom-gamepadbutton-value
2. Do not allow triggers to be used as an `Axis`: see https://github.com/bevyengine/bevy/blob/340957994dc2c85f7a3ebc5ea6a5ad1b161e0041/examples/input/gamepad_input.rs#L23 for a confusing example.
3. (PERF): Specialize buttons based on them being analogue / digital, and skip the repeated conversions and confusion.

## What alternative(s) have you considered?

1. Eliminate `ButtonSettings` completely.
2. Only expose a binary value to end-users.
3. Store the received button input value as a `bool` as soon as we receive it from `gilrs`.

I would probably prefer a
```rust
enum ButtonState {
Pressed,
NotPressed
}
```
as our representation oif this data, but even a `bool` would be significantly better than our current `f32`.

This solution is not as good as the above, as it is not standards compliant and doesn't handle triggers nicely (they're clearly buttons, not axes).

## Additional context

Identified in #3246.