Removed persistent side effects from calls to `highlight()`.

This was probably the weirdest bug I can remember in this project.

It all started with tests breakage after the 3495b9e (replacing
`utility.languagesList()` with `hljs.listLanguages()`) that only
affected my local machine. And only the node.js build, the old
browser test suite was working fine. That was weird.

The lists returned by those functions had the same items but in a
different order. Which meant that there were apparently some side
effects affecting other languages down the list. That was weird.

The broken language was Dust.js which is an HTML templating
language and its highlighting definition includes HTML as a
sub-language. The problem manifested itself in the way that all
HTML tags in the Dust code were marked up as XML processing
instructions `<?...?>`. And though those have a rather high
relevance score, the final result for the test Dust snippet was
way lower than the expected: 2 vs 8. That, surely, was weird.

Using the famous "catching a lion in the desert" algorithm I
narrowed down the languages list to just two: LiveCodeServer and
Dust. Highlighting LiveCodeServer was consistently breaking Dust.
At that moment I thought it was weird, but little did I know…

I started removing modes from LiveCodeServer definition to find
which one was responsible. But even removing all of them didn't
change a thing: Dust was still failing, even after calling
highlighting of an empty language. Now *that* was weird.

At 3am I had no other choice than going to sleep.

I started the next day by successfully reproducing the bug with
the browser build: it had to have the LiveCodeServer snippet to
be before the Dust one. And then I was going to file this issue on
GitHub, as I had no idea when it could be fixed. I was writing
something like this:

> The problem happens after calling LiveCodeServer highlighting
> (both automatic and explicit) ...

And then I realized that I don't remember actually trying to
call LiveCodeServer highlighting explicitly. And as you probably
already have guessed explicit highlighting didn't trigger the bug!
Weird.

What automatic highlighting does that explicit doesn't is trying to
apply all the known languages to a code snippet. So it was the
LiveCodeServer *snippet*, rather than the definition, that was
triggering the bug. Further investigation proved the hypothesis:
it was application of the Dust highlighting to the LiveCodeServer
snippet that broke subsequent highlighting of Dust itself. That
was… well, at this point it actually started to make sense.

The trick that we use to highlight templating languages intermixed
with HTML is to keep the parser state between disjoint chunks of
HTML code to maintain correct markup when, say, a template tag
appears in the middle of an HTML attribute. And the place where
we keep this parser state is the compiled language object, which
effectively is a singleton. So calling the Dust highlighting on
the LiveCodeServer snippet left the HTML language object (used by
Dust) in an intermittent state of the opened processing
instruction which continued indefinitely during all later calls to
the Dust highlighting. Gotcha!

To fix this we now store the continuation parser state in a local
variable instead of attaching it to the language. I'm concerned
though with the commit 122cbbc that explicitly made it the way it
was before, but I don't remember why.