Fixing issue: textToModel adds extra face

[perminder-17]

Solves issue : #7474

[perminder-17]

https://editor.p5js.org/aman12345/sketches/Qp1A_qgnj

hey @davepagurek,
I've partially implemented the earcut algorithm, but I still need to handle cases for 3D models. Before I fully implement it for all 3D models, I wanted to ask for your opinion. Currently, the model isn't completely correct—there are still a few extra faces visible.

I can confirm that the number of extra faces is lower than what we experienced with the libtess algorithm; the earcut algorithm has noticeably improved the outcome.

So, should implementing earcut() still worth? If yes, I will work on the 3d part, because still it doesn't solves our problem fully.

Also, If you try to run the sketch, you can see the log values of the deviation.

Deviation basically returns the relative difference between the total area of triangles and the area of the input polygon. 0 means the triangulation is fully correct..

The deviation is still not zero and it's very very close to 0, and I believe that even if it were, there might still be some extra faces.

[davepagurek]

So it looks like this won't fully fix #7474, so it could be worth pausing this to explore the other potential ways to fix this I mentioned in #7474 (comment), since fixing the buggy behaviour is probably higher priority than changing the algorithm, but I think this effort is worth picking up after that for its other potential benefits of using a more maintained codebase and potential performance improvements (I tested it out a bit here https://editor.p5js.org/davepagurek/sketches/gmd_WPXX9 in the past and saw a ~5fps improvement on this test case? We can double check that the same applies here.)

With the checks for clockwise/counterclockwise/containment, do you still see the performance of earcut being better than libtess if you were to run the algorithm every frame? e.g. drawing text from contours directly in draw() every frame, not caching in geometry.