Small string optimization (SSO)

[bnoordhuis]

Something to investigate: is SSO a worthwhile memory saving? My hunch says yes for 64 bits builds, no for 32 bits builds.

32 bits builds use NaN boxing. I don't think there's enough room left to store anything meaningful. On 64 bits systems:

1. a JSValue is a 64 bits type tag + a 64 bits inline value or pointer

2. There are only ~15 type tags at the moment; let's carve out space for 32 just in case

That leaves 64 + 64 - 5 = 123 bits or 15 bytes for storing strings inline, and there are several clever schemes for storing strings even longer than that.

Implementation caveats:

• On little endian systems, the type tag is in the first byte, leaving the remaining 15 bytes as contiguous storage. Big endian systems are penalized because they have to perform a left or right shift whenever they access or store the type tag. Approximately no one uses BE systems anymore so probably not a huge concern.

• quickjs.c directly accesses JSString fields all over the place; p->len and p->u.str8 in particular. Adding a layer of indirection introduces some overhead but hopefully that's offset by memory and refcount savings