We can't freely concatenate strings in the background because they
could be mutated by the main thread (eg, flattened, internalized,
externalized...).

So, when there is a JSAdd between 2 constant strings, we first checked
if they are "safe" (= internalized, I think), and if so, we
concatenate them at compile time. If they are "unsafe", then we don't.

It turns out that this wasn't an issue with delayed constant strings,
since the content of the strings were never accessed: the actual
concatenations were done on the main thread, where it's safe to do.

This CL fixes that for most cases:

  - if the strings really cannot be read from the background, but the
    length of their concatenation is more than ConsString::kMinLength,
    then we create a ConsString.

  - I added a set to record which strings we created in the turbofan:
    those strings can safely be accessed from turbofan regardless of
    their type.

The only case where delayed constant strings could be a bit better is
when there is a concatenation of 2 small non-internalized string,
because right now, we wouldn't fold it. Still, it should happen very
rarely, if ever.


Bug: chromium:1359941
Change-Id: I651b834273de89f1e3c60654094a4606dd9c62f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3891252Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83251}