Use Isometry in bevy_gizmos wherever we can

[RobWalt]

Objective

• Solves the last bullet in and closes Tracking issue: Isometry follow-ups #14319
• Make better use of the Isometry types
• Prevent issues like Grid gizmo seems hard to handle #14655
• Probably simplify and clean up a lot of code through the use of Gizmos as well (i.e. the 3D gizmos for cylinders circles & lines don't connect well, probably due to wrong rotations)

Solution

• go through the bevy_gizmos crate and give all methods a slight workover

Testing

• For all the changed examples I run git switch main && cargo rr --example <X> && git switch <BRANCH> && cargo rr --example <X> and compare the visual results
• Check if all doc tests are still compiling
• Check the docs in general and update them !!!

---

Migration Guide

The gizmos methods function signature changes as follows:

• 2D
  • if it took position & rotation_angle before -> Isometry2d::new(position, Rot2::radians(rotation_angle))
  • if it just took position before -> Isometry2d::from_translation(position)
• 3D
  • if it took position & rotation before -> Isometry3d::new(position, rotation)
  • if it just took position before -> Isometry3d::from_translation(position)

[RobWalt]

Here are just some screenshots. This PR also fixes the capsule and cylinder primitive rendering which was broken in the mean time somehow. (The circles connecting points with the orthogonal lines aren't exact)

Before:

After:

---

Funnily enough I also didn't change any parameters and I don't know why it looks so "simple" in the before-version 🤔

[NiseVoid]

Haven't reviewed everything in detail, but the changes overall look fine to me. The changes from a direction to the weird Isometry::from_rotation(Quat::from_rotation_arc()) seems a but ugly, but I don't think we have a nicer solution for that currently.

[janhohenheim]

Wouldn't it be nicer to accept impl Into<Isometry3d> everywhere instead of Isometry3d? That would make this API a bit more robust regarding future usability additions.

[alice-i-cecile]

Wouldn't it be nicer to accept impl Into<Isometry3d> everywhere instead of Isometry3d? That would make this API a bit more robust regarding future usability additions.

Possibly, but isometry is a really useful type, and that will increase complexity and compile times here.

[janhohenheim]

@alice-i-cecile given that Bevy uses Transform nearly everywhere, I'd argue that accepting an impl would decrease complexity for users, as they don't need to care about the mathematical concepts at play here and can have it "just work". I agree that Isometry is cool, but I don't think most users will care about the difference between it and Transform.
Since setting up gizmos is not an operation that happens in many places, I'd be surprised if accepting an impl had any measurable effect on compile times for an average plugin.
This is not a strong opinion, feel free to disregard if you disagree.

[alice-i-cecile]

Yeah I don't feel super strongly either, but I'd like to merge this as is and then refine later.

[janhohenheim]

@alice-i-cecile that's fair :)