Give the parsing threads more stack, and quiet a recovered Prism panic

[dduugg]

Summary

Two fixes from a review of #73 after it merged. Neither problem has been released, since #73 didn't bump the version.

• Deeply nested files no longer abort pks. Prism parses recursively, as pks's walk of its tree does, so each level of nesting takes stack. On a rayon thread's default 2 MiB, about 1,400 to 2,500 levels of nested calls, hashes, arrays or blocks overflowed it, and the whole run aborted with fatal runtime error: stack overflow. lib-ruby-parser held 16,000 levels or more. The global thread pool's threads now get 16 MiB, and so does the thread the command runs on, since rayon parses a lone file, as check <file> and check-contents have, on the thread that asks.
• No panic text before the non-UTF-8 warning. pks recovers from the panic that Diagnostic::message raises on a message that isn't UTF-8, but Rust's default panic hook printed it first, with a path into the cargo registry, so the run looked as if it had crashed. Now the warning is all that prints.

Design notes

• Why 16 MiB. Prism stops nesting most constructs after 10,000 levels and reports "nesting too deep". In a release build with 16 MiB, each of 14 constructs nested 12,000 deep parses with that warning. 8 MiB still overflows on arrays, parentheses, !, splats and indexes.
• What 16 MiB doesn't hold. Prism doesn't cap everything. Method chains and elsif chains are flat in Prism's grammar but deep in its tree, and they overflowed 2 MiB only past about 16,000 levels; with 16 MiB, a chain of 100,000 links parses and one of 200,000 aborts. Nested case/in array patterns abort between 30,000 and 40,000 levels, and hash patterns between 20,000 and 30,000. A real fix for those needs walks that don't recurse.
• The command's thread. On the main thread, which has 8 MiB on macOS and Linux and 1 MiB on Windows, a single file nested 9,990 deep aborted check and check-contents even with 16 MiB on the pool. cli::run keeps the global pool and spawns a thread for the command, rather than running the command in a pool with install, so that the command doesn't hold one of the pool's threads: with RAYON_NUM_THREADS=1, jwalk would wait a second for the busy pool and then walk nothing.
• Cost. A thread's stack is reserved, not committed, so peak memory on two large Rails apps is unchanged. The machine was busy while I measured, so I don't claim a timing result, though hyperfine showed no difference beyond its noise.
• The panic hook. ruby-prism has no way to read a message that can't panic, so pks still catches the panic. The hook it installs leaves out only a panic raised while a message is being read, on that thread, and passes every other panic to the hook it replaced. The proper fix belongs in ruby-prism, where Diagnostic::message could replace invalid bytes instead of panicking.
• The tests' depths. A debug build takes more than ten times the stack per level. It overflows 2 MiB at about 200 levels of nested arrays, 8 MiB at about 700 and 16 MiB at about 1,350, so the list-references test nests 500 and the check test 1,000.

Test plan

• New test: list-references on 500 nested arrays, under both parsers. It aborts without the pool's stack.
• New test: check on one file of 1,000 nested arrays, under both parsers. It aborts on the main thread without the command's thread.
• The non-UTF-8 test now requires stderr to be exactly the warning. It fails without the hook.
• New test: a panic after a recovered one still prints. It fails if the hook swallows every panic, never sets or never clears its flag, or isn't installed.
• With a release build, check <file>, check-contents and list-references on a file nested 9,990 deep finish under both parsers.
• cargo fmt --check, cargo clippy --all-targets --all-features -- -Dwarnings and the full suite pass.