Restructure: Migrate away from `decorations`

[jonschz]

At the moment, this library uses the decorations module to achieve the n-fold effect. This has several disadvantages:

• All arrow heads must be re-implemented manually, so very few are supported (see #5)
• Numerous path lengths are computed unnecessarily, which leads to long compile times
• There are several glitches rooting from this rather unconventional use of the decorations module (e.g. #4)

Alternatively, nfold could overwrite \pgf@stroke@inner@line from pgfcorepathusage.code.tex and draw the current soft path in a modified way, hijacking the point where /tikz/double enters the rendering pipeline. Code to parse the soft path could be borrowed from pgfmoduledecorations.code.tex.

[Qrrbrbirlbel]

I myself am always a bit intimidated be decorations since you can't access many informations in each state (at least it appears that way to me but I don't use them much anyway).

It would be best to “patch” \pgf@stroke@inner@line in my opinion (obviously with a switch so that the original double is still available).

For the arrow tips, my idea would be to add a y-dependent version of \pgfarrowssetlineend (this needs to be done to every arrow tip that hasn't a vertical back) so that each extra line could be shorten by a different amount.

This however would mean that these values somehow need to be accessed inside \pgf@stroke@inner@line which seems to be tricky or needs a lot of reworking a lot about arrow tips and things like \pgf@prepare@end@of@path/\pgf@prepare@start@of@path.

The file pgfcoreprocessing.code.tex contains \pgfprocessplitpath which can split a path at their movetos.

It also has \pgfprocesspathextractpoints which can return the start and end vector of a (sub)path which should help with closed paths. (It also has \pgfprocesscheckclosed.)