Replace axis-like input configuration with new input processors

[Shute052]

Objective

• Parts of Input Processors #491 to replace the existing ones with new input processors.
• Fixes Sensitivity applied before deadzone for dual axis inputs #495.

Solution

Added input processors for SingleAxis, DualAxis, VirtualAxis, and VirtualDpad to refine input values:

• Traits:
  • AxisProcessor: Handles single-axis values.
  • DualAxisProcessor: Handles dual-axis values.
• Built-in Processors:
  • Pipelines: Combine multiple processors into a pipeline.
    • AxisProcessingPipeline: Chain processors for single-axis values.
    • DualAxisProcessingPipeline: Chain processors for dual-axis values.
  • Inversion: Reverses control (positive becomes negative, etc.)
    • AxisInverted: Single-axis inversion.
    • DualAxisInverted: Dual-axis inversion.
  • Sensitivity: Adjusts control responsiveness (doubling, halving, etc.).
    • AxisSensitivity: Single-axis scaling.
    • DualAxisSensitivity: Dual-axis scaling.
  • Value Bounds: Define the boundaries for constraining input values.
    • AxisBounds: Restricts single-axis values to a range.
    • DualAxisBounds: Restricts single-axis values to a range along each axis.
    • CircleBounds: Limits dual-axis values to a maximum magnitude.
  • Deadzones: Ignores near-zero values, treating them as zero.
    • Unscaled versions:
      • AxisExclusion: Excludes small single-axis values.
      • DualAxisExclusion: Excludes small dual-axis values along each axis.
      • CircleExclusion: Excludes dual-axis values below a specified magnitude threshold.
    • Scaled versions:
      • AxisDeadZone: Normalizes single-axis values based on AxisExclusion and AxisBounds::default.
      • DualAxisDeadZone: Normalizes dual-axis values based on DualAxisExclusion and DualAxisBounds::default.
      • CircleDeadZone: Normalizes dual-axis values based on CircleExclusion and CircleBounds::default.
• App extensions: register_axis_processor and register_dual_axis_processor for registering processors in the bevy::prelude::App.
• Procedual macro attribute: serde_typetag for adding type tags for processors.

TODO

• Add new examples for processors.
• Add new examples for inputs using processors.

Known Issues

• Deserializing generic trait objects directly in Rust presents a current limitation. As a workaround, we need to define a corresponding concrete type for each desired value type used with the trait.

Changelog

• Replace DualAxisShape with new deadzones.
• Replace functions for inversion, sensitivity, and deadzone creation with processor constructors.

Internal changes

• Add dependency to typetag, dyn_clone, dyn_eq, dyn_hash for boxed dyn trait objects, ensuring object-safety.
• Refactor the logic of InputStreams::input_value to use these processors.

[Shute052]

the rounded square deadzone seems to be a bit... dead

[alice-i-cecile]

Generally quite pleased with this abstraction, and the builder pattern used! It makes a lot of sense to me. Code quality and docs are exceptional, you've done an awesome job there.

However:

1. The pipeline work is super cool, but not needed for an MVP. I'm opposed to merging it in our initial implementation, and will require benchmarks to merge it in a followup. Simply storing a Vec<Box<dyn AxisProcessor>> is a fine design to start with.
2. Some cleanup to do: the region comments should all be gone.
3. Fewer macros. The Reflect for trait objects one can stay, but the others should be cut. They're relatively hard to maintain, and will be a serious barrier to upstreaming into Bevy.
4. typetag cannot be used, flat out. It's incompatible with WASM builds, so we need to redesign to strip it out. See Support static constructors (ctors) rustwasm/wasm-bindgen#1216.

[alice-i-cecile]

The processors still need to be removed from this PR. I also don't quite understand why all of the typetag stuff is needed in the first place. Is this just for serialization of processors? I would really like to avoid introducing the associated complexity and dependencies, and would frankly rather sacrifice the ability to store arbitrary preprocessor functions than add it.

I understand if that's not the path you'd prefer to take: I'm happy to adopt this excellent work and finish it up on my own if you'd like.

[alice-i-cecile]

Okay, I'm satisfied now. To rehash from our conversation on Discord:

1. Pipelines are much simpler now, and just store a Vec<Boxy dyn Processor>.
2. We need typetag-style functionality for serialization of boxed trait objects. While we could move away from trait objects here, in favor of a finite set of operations, it won't actually trim complexity / dependencies in the end.

The case for using trait objects for input types is dramatically stronger, as is the need for serialization.

Merging!