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 #3246 (comment).

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

   bevy/examples/input/gamepad_input.rs

   Line 23 in 3409579

   let right_trigger = button_axes

   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

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.