When placing a new point on a non-closed path, the expected behavior is
that the point would be placed a distance from the scene camera equal to
the distance from the scene camera and the last point on the spline.
However, distance was being computed by comparing the scene camera's
global coordinates and the end point's local coordinates, meaning the
computation would only be correct when the parent game object is located
at the scene origin.

Modified the distance computation to compare distances using the end
point's global position. Also added a check to pick the "end point"
based on whether the new point is getting appended or prepended.

Tested manually in scene with a PathCreator component.

When building a path on top of a given scene, may intuitively expect to
click on points in the scene geometry to add path segments. However, the
path creator always creates points a pre-specified distance from the
editor camera.

Added a raycast check that looks for potential geometry the user may be
clicking on. If there is geometry close to the pre-specified distance, a
point will be generated at the ray intersection. Otherwise, we fall back
to the original behavior.

Tested manually in editor.

* added test scene/script that checks if the position returned by GetClosestPointOnPath is almost identical to the input position if the input position is on the path already.

* added functionality to the test the old GetClosestPointOnPath, GetClosestTimeOnPath and GetClosestDistanceAlongPath results with the upcoming optimized implementations.
added functionality to profile the old and new implementations.
added scene that visualizes a position near the path and its actual old and new GetClosestPointOnPath results.

* Optimized VertexPath.CalculateClosestPointOnPathData method.

On my PC, with the provided test scene "GetClosestPointOnPath Test" the profiling results are:
- Old implementation: 5.58ms - 14.62ms
- New implementation: 0.25ms - 0.40ms

The idea for the optimization is to do the math in "VertexPath local-space" rather than world-space.
This optimization thus avoids to transform hundrets or thousands of path positions to world-space.
It only applies two transformations instead: One to transform the incoming worldPoint into local-space and then a transform of the computed result from local- to world-space.

…ormance

Sometimes the num variable in the method for rotating the normals by user angle was equal to 1 -> 1 - 1f is 0 so you'd get NaN due to dividing by 0.

Fix null ref exception: add default constructor to initialise bezierpath instance