Slow rendering of inputs with many paths

Nobody has claimed this yet.

resvg performs poorly on input files with many tens of thousands of individual paths. Attached are two files, slow.svg and fast.svg. slow.svg contains approximately 100k elements with some style and transform set. Most of the paths have only two nodes. Converting it to PNG using resvg at 300 dpi takes approximately 15 minutes on a recent laptop AMD ryzen CPU.

fast.svg is a version of the file, where most of the 100k paths have been merged into a single path using some vim magic. It renders in less than one second everything else being the same.

These test files are produced by gerbv, a gerber viewer. gerbv uses Cairo's SVG canvas to generate these.

Here is a plot of resvg's performance with an increasing number of input paths:


This graph shows sub-linear performance beyond ~1000 input paths. Note that all tests have been run in parallel, so performance for shorter durations is probably under-estimated and for longer durations performance is likely over-estimated due to CPU congestion getting better the longer the test went on.

Test files:
[testfiles.zip](https://github.com/RazrFalcon/resvg/files/7966365/testfiles.zip)

Start by extracting testfiles.zip and reproducing the reported PNG conversion timings for slow.svg and fast.svg at 300 dpi. Compare performance as the number of paths increases, using the issue's plot as a reference. Done means substantially improving rendering time or scaling for inputs with tens of thousands of paths without changing the rendered result.

Written by the indexing model from the issue text.