Ensure they do not terminate prematurely for paths
with a step of 0 or exceptionally small values
when a valid stroke-width is present.
In my opinion, the optimal approach was to separate vertex generation
into dedicated methods: strokeRoundPoint and strokeSquarePoint.
My update supports two different stroke-cap styles.
I have also tested it with various files (JSON, SVG)
as well as a small example application similar
to the one included in the previous pull request (#3066).
issue: https://github.com/thorvg/thorvg/issues/3065
ThorVG pImpl idiom caused internal data to be scattered
across hierarchical classes. This refactoring consolidates
the data by inheriting pImpl internally, reducing memory
allocation counts and eliminating unnecessary strategy methods.
Basically rewrite the PathTrim code, correct the Line and Bezier split
function calling.
Also the trim situation where start is greater than end can be handled correctly.
* restrict the scissor box of composite task
* do not tessellate stroke or fill geometry if there is no Fill or
Stroke color
* use actually transformed curve to calculate polyline count when doing
curve flatten
* add new render task to do stencil and cover rendering which is a
fallback rendering method to handle cases that trianglation tessellation
failed
* add a new tessellator to generate stencil and cover vertex mesh
* merge vertices that are close enough before tessellation
* append return branch in tessellation to prevent dead loop caused by floating point precision
