Improve cubic segment bezier functionality

[hocop]

Objective

• Fixes CubicSegment lacks functionality of CubicCurve #17642

Solution

• Implemented method new_bezier(points: [P; 4]) -> Self for CubicSegment<P>
• Old implementation of new_bezier is now new_bezier_easing(p1: impl Into<Vec2>, p2: impl Into<Vec2>) -> Self (breaking change)
• added method new_bezier_with_anchor, which can make a bezier curve between two points with one control anchor
• added methods iter_positions, iter_velocities, iter_accelerations, the same as in CubicCurve (copied code, potentially can be reduced)
• bezier creation logic is moved from CubicCurve to CubicSegment, removing the unneeded allocation

Testing

• Did you test these changes? If so, how?
  • Run tests inside crates/bevy_math/
  • Tested the functionality in my project
• Are there any parts that need more testing?
  • Did not run cargo test on the whole bevy directory because of OOM
  • Performance improvements are expected when creating CubicCurve with new_bezier and new_bezier_easing, but not tested
• How can other people (reviewers) test your changes? Is there anything specific they need to know?
  • Use in any code that works created CubicCurve::new_bezier
• If relevant, what platforms did you test these changes on, and are there any important ones you can't test?
  • I don't think relevant

---

Showcase

// Imagine a car goes towards a local target

// Create a simple `CubicSegment`, without using heap
let planned_path = CubicSegment::new_bezier([
    car_pos,
    car_pos + car_dir * turn_radius,
    target_point - target_dir * turn_radius,
    target_point,
]);

// Check if the planned path itersect other entities
for pos in planned_path.iter_positions(8) {
   // do some collision checks
}

Migration Guide

This section is optional. If there are no breaking changes, you can delete this section.

• Replace CubicCurve::new_bezier with CubicCurve::new_bezier_easing

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[mweatherley]

Not a fan of the code duplication, but I guess that's kind of unavoidable 🤔

I think there's a reasonable shot that all of these will be outmoded by the Curve API implementations in the future, but for now it's more ergonomic, I guess.

(E.g. one right now can write something like

cubic_segment.with_two_derivatives().map(|j| j.second_derivative).samples(n)

to similar effect, and the intention is for this to become more ergonomic in the near future.)

[hocop]

Maybe it's better to move these functions to a separate trait, and implement it on both CubicCurve and CubicSegment. This can help avoid some duplication. What do you think?

[mweatherley]

You can delete the entire cfg_attr block at like 1016 if you want CI to stop complaining :)

[Carter0]

I think the code and doc comments look good. You might want to add some labels to your PR though if you can. Sometimes people skip over PR's if they don't have labels.