The .hljs-tag here spans two lines, however, the text() XPath function will trim the newline so the XPath that was introduced in #79 doesn't work.

Original Code

<?xml version="1.0" encoding="utf-8" ?>
               <tag a="t"
                        b="t">
                 </tag>

Highlighted Result

<span class="hljs-meta">&lt;?xml version="1.0" encoding="utf-8" ?&gt;</span>
               <span class="hljs-tag">&lt;<span class="hljs-name">tag</span> <span class="hljs-attr">a</span>=<span class="hljs-string">"t"</span>
                        <span class="hljs-attr">b</span>=<span class="hljs-string">"t"</span>&gt;</span>
                 <span class="hljs-tag">&lt;/<span class="hljs-name">tag</span>&gt;</span>

I have tried changing the XPath to use . instead of text(), however, that will match deeply nested newlines like those seen in #79 and multiply the number of "results" this XPath returns relative to the depth of the span that contains it.

Running the 9.18.1.5 release splits the above snippet in ~29 seconds for 200000 iterations using text() (however, it's incorrect in its splitting); replacing text() with . results in a time of ~34 seconds in the exact scenario but splits correctly.

This PR without XPath and manually searching for newlines inside of spans comes in at ~34 seconds for 200000 iterations as well.

I have taken a step back and rewritten this function entirely to no longer parse the HTML into a DOM object. I am now using pure regular expressions to do our best in figuring out which tags span multiple lines.

The solution in this PR functions as such:

1. With the highlighted code snippet result above, I split things on \R and I count how many opening and closing span tags there are on each line.
2. If we find an even amount of closing and opening tags, we move on to the next line
3. If there are an uneven amount of closing tags with opening tags, that means we found a span tag that spans multiple lines.
4. I remove all complete <span>...</span> tags from a copy of the current line
5. I then match all of the opening span tags and save them for our next line
6. I then count how many open tags there are and put them at the end of the current line
7. In the next line, if I have anything saved from step 5, then I add them as a prefix to the current line in this iteration

Without parsing the HTML into a DOM object, I've decreased the speed of 200000 iterations down to ~10 seconds.

See westonruter/syntax-highlighting-code-block#246

/cc @westonruter