…t of string'

deserializeMessage() would not recognize escape sequences at the start
of a string, due to a simple falsey check on `match?.index` which could
be validly 0 instead of null.

In other words: "Foo\x3bBar" would decode to "Foo;Bar", but "\x3b" would
not be recognized as an escape sequence.

This fixes that bug, enabling those suppressed test cases, and disables
the newly-failing tests which had only passed due to the (still-broken)
escaping logic being skipped in those situations.

The original implementation confused escaped and un-escaped sequences
due to squashing each adjacent pair of backslashes prior to parsing.

Unlike encoding, decoding cannot be performed in passes this way: it
must be sequential, because of the potential for overlapping patterns
(e.g. the third backslash in "\\\x3b").

This replaces the implementation with a single sequential regex, which
matches the escape sequences and replaces each match. This enables the
tests that were broken in the previous implementation.

To illustrate, given the following two different original values (here
as literals between «», without any escaping):
  a. «Packing\Stuff\x3BEarmuffs»
  b. «Packing\Stuff;Earmuffs»

Those should be distinctly encoded as:
  a. «Packing\\Stuff\\x3BEarmuffs»
  b. «Packing\\Stuff\x3BEarmuffs»

The original implementation wrongly threw away the escaping information
by replacing each adjacent pairs of backslashes with a single backslash,
regardless of whether escaping was in effect or not:
  a. «Packing\Stuff\x3BEarmuffs»
  b. «Packing\Stuff\x3BEarmuffs»

The new implementation matches, in (a), each "\\"; and there are no
non-overlapping "\x…" sequences. In (b), the first "\\" is matches, and
the "\x3B" is matched.

This works for any correct combination of adjacent escape squences.