Speed-up html-escaping using jetscii (waiting for portable-simd)

[Kijewski]

$ cargo bench --bench escape

Before the PR:           [3.6464 µs 3.6512 µs 3.6564 µs]
Impl. without `jetscii`: [3.4837 µs 3.4899 µs 3.4968 µs] ~ 95 % of baseline
Impl with `jetscii`:     [2.0264 µs 2.0335 µs 2.0418 µs] ~ 55 % of baseline

Until portable SIMD gets stabilized, I don't think we can do much for non-X86 platforms. And even after it is stabilized, I guess any optimizations should be implemented upstream in memchr and/or jetscii.

[Kijewski]

Using a bit test in here makes the benchmarks run slower. It could be that the benchmarks outline an unrealistic scenario, though: They consist of comparatively long strings.

Bit testing is slower than a table lookup, if the table is already loaded into the CPU cache, but loading the table takes quite some time _once_, too. If the strings are mostly short, and mostly contain no characters that need escaping, then a bit test solution would win.

I guess the current solution is good enough for now. Just something we need to keep in mind, that we might need to revise the benchmark text corpus. Even the "short" string is 27 characters long.

[GuillaumeGomez]

I'll take a look once rebased. ;)

[Kijewski]

Rebased. For now, that's the last one in my "let's make it speedy" series. :)

[Kijewski]

I excluded x86 (32bit). That makes the code a bit more readable, and if you still use a 32bit x86 system in 2024, then yeah, chances are that you run your code on some aching VIA processor without SSE 4.2 support.