Bug: long strings with REALLY long delimiters…

[nobody <nobody+lua-list@...>]

…like [===…===[a]===…===] cause all sorts of weird behavior (incl.
crashes) in 5.3.x / 5.4 (git HEAD).  Try

local eqs = ("="):rep(0x3ffffffe)
local code = "return ["..eqs.."[a]"..eqs.."]"
print(#assert(load(code))())

It might segfault, it might print a huge number instead of 1 (or, minus
the '#', print 'a]===…===]<<garbage>>' instead of a single 'a').

And with ASAN (-fsanitize=address) you get told more gory details, like
that it's trying to do a 0x1_0000_0001-long read (4GiB plus 1 Byte… that
read size is stable over the next couple extra ='s).

I haven't deeply looked into this, from a cursory glance it might be
(partly?) caused by the separator length being tracked in an `int`,
which affects (in 5.4/git)

llex.c:251: skip_sep (return, locvar on next line)
llex.c:264: read_long_string (funarg)
llex.c:447: llex (locvar)

A quick test (int --> ptrdiff_t in those 4 places) _seems_ to fix it,
but there might be more…

-- Marco