Fix gizmo clipping again (#21503)

# Objective

- alternative to #21502
- also undoes #20890
- does not regress #19205
- fixes #21489 and #21479

## Solution

the fix i originally made was wrong. the reason it worked was because it
failed the conditional and did not clip the lines in some cases where
the original bug was exhibited. the condition was correct before, it
turns out, but the clipping logic is wrong: an epsilon is added, with a
comment saying it is to avoid falsely culling the vertex due to floating
point imprecision leaving it just barely in front of the near plane.
However, i do not see why an epsilon should be needed here, or why this
should be avoided: triangle primitives are regularly intersecting the
clipping plane, that is standard order of business. The entire primitive
is not discarded if only part of it is clipped, instead only the visible
pixels are rasterized.

## Testing

- original bug test case by Antony looks right
- both grid test cases look right
- gizmos examples look right

Author: atlv24

crates/bevy_gizmos/src/lines.wgsl

@@ -137,14 +137,11 @@ fn vertex(vertex: VertexInput) -> VertexOutput {
 
 fn clip_near_plane(a: vec4<f32>, b: vec4<f32>) -> vec4<f32> {
     // Move a if a is behind the near plane and b is in front.
-    // equivalent to `a.z / a.w > 1.0 && b.z / b.w <= 1.0` but avoids divs
-    if a.z * sign(a.w) > abs(a.w) && b.z * sign(b.w) <= abs(b.w) {
+    if a.z > a.w && b.z <= b.w {
         // Interpolate a towards b until it's at the near plane.
         let distance_a = a.z - a.w;
         let distance_b = b.z - b.w;
-        // Add an epsilon to the interpolator to ensure that the point is
-        // not just behind the clip plane due to floating-point imprecision.
-        let t = distance_a / (distance_a - distance_b) + EPSILON;
+        let t = distance_a / (distance_a - distance_b);
         return mix(a, b, t);
     }
     return a;