Rewriteis_ascii using slice::as_chunks

[Kmeakin]

Generalize the x86-64+sse2 version of is_ascii to be architecture-neutral, and rewrite it using slice::as_chunks. The new version is both shorter (in terms of Rust source code) and smaller (in terms of produced assembly).

Compare the assembly generated before and after:
https://godbolt.org/z/MWKdnaYoK

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[hanna-kruppe]

The simpler source code and shorter assembly seem to boil down to two changes:

1. Using unaligned loads for every full chunk, instead of trying to align all loads except possibly the first and the last one.
2. Always using the simple byte-by-byte loop for the last bytes.len() % CHUNK_SIZE bytes, instead of trying to handle it with an unaligned load that overlaps with the preceding chunk.

The first one seems quite reasonable in many cases. It probably causes a huge performance regression for targets that don't have efficient unaligned loads, but to be fair, those are becoming less common and less important over time.

The second change may be quite problematic for some common input sizes, though. Try benchmarking before vs. after on an input that's 2 * CHUNK_SIZE - 1 bytes long, or with a random short input lengths that make the branches and iteration counts less predictable.

[okaneco]

There are some benchmarks in library/core/benches/ascii/is_ascii.rs and I added more in #130733, also a codegen test.

When I originally made that PR, new uses of const_eval_select seemed to be discouraged when making a function const, and then the situation was a little different by the time it was reviewed and merged.

However, the usize-aligned path is probably still needed for targets without SIMD like i586-unknown-linux-gnu since it can do SWAR ASCII checks instead of byte at a time.