Fix normals of very large SphereMesh and CapsuleMesh

[Flarkk]

SphereMesh and CapsuleMesh compute their sphere normals by normalizing the vertex position.
Normalizing involves squaring the vertex coordinates, which generate INFINITE values if at least one of the coordinates is larger than sqrt(MAX_FLOAT_VALUE).
With 32 bit floats, this threshold value is ~1.84E19. With 64 bit floats it's ~1.34E154.

This PR fixes this behavior by dividing the vertex position by the radius before normalizing.
This doesn't change the end result of the normalization, but avoid running into the floating point precision issue.

[EDIT] This PR fixes this behavior by working with unit length vectors all the way down, and scaling with radius only to calculate vertex positions.
Radius is not involved anymore in normal computation logic, which avoids running into the floating point precision issue.

I tested the other primitives and all of them are fine with normals.

	Normals with this PR	Normals without
SphereMesh of radius 1E28
CapsuleMesh of radius 1E28

Note : I stumbled upon this issue by working on #95944.
Being able to render very large primitives can be useful in very large worlds (space sims, terrain generation ...).

[fire]

Ok with the theory of the enhancement. Did not review yet.

[Flarkk]

@fire would you have time now to review this one ?

[fire]

That's neat; the rearranging of the equations reduces the precision loss.

I would like someone from the rendering to review the equations, too.

[Flarkk]

Good. Best if you can ping this person right here then. Thanks !

[BlueCube3310]

Looks good to me. I compared the meshes and their UV channels and they look the same, so the equations are correct

[Repiteo]

Needs rebase before this can be merged

[Flarkk]

Will do tomorrow

[Flarkk]

Here we go

[akien-mga]

Thanks!