Precompute the Rader's permutation

[HEnquist]

Rader's reorders the input by walking g^k mod len, one strength-reduced modular multiply per
element, in a serial chain recomputed on every call. This builds the sequence once at construction
instead.

• each step is two 64x64->128 widening multiplies. wasm has no high-multiply opcode, so LLVM emits
  two call __multi3 plus a linear-memory round trip per element there, where aarch64 does it in
  seven instructions
• one Box<[u32]> covers both directions: the inverse walk is that same table read backwards and
  rotated by one, since g^-k == g^(len - 1 - k)
• costs 4 * (len - 1) bytes per instance, about 400 KB near len 100000, the same order as what
  avx_raders.rs and Bluestein's already store
• M1, f64, eight smooth primes from 1009 to 100801: 1.24x to 1.61x. Under wasm the per-element
  permutation cost drops from 25.2-26.9 ns to 1.87-3.07 and Rader's comes out 1.9-3.5x faster

[ejmahler]

one Box<[u32]> covers both directions: the inverse walk is that same table read backwards and
rotated by one, since g^-k == g^(len - 1 - k)

This is what was stopping me before, I was never able to figure out how to reuse the same buffer for both reorders. This is great work, thank you. Perhaps we should reconsider the raders vs bluestein's tuning with this in mind. Not necessarily as a part of this PR.

I'll review next week.

[awxkee]

Interesting, so twiddles generation could also be:

let (first_half, second_half) = inner_fft_input.split_at_mut((len - 1) / 2);
let mut twiddle_input = 1;
for (input_cell, conjugate_input_cell) in first_half.iter_mut().zip(second_half) {
    let twiddle = twiddles::compute_twiddle(twiddle_input, len, direction);
    *input_cell = twiddle * inner_fft_scale;
    *conjugate_input_cell = input_cell.conj();

    twiddle_input =
        ((twiddle_input as u64 * primitive_root_inverse) % reduced_len) as usize;
}

[HEnquist]

Nice catch, thanks. Implemented this and benchmarked construction time before/after (the process() benches don't touch this since it's all in new()). Solid win across most sizes, roughly 15-28% faster for mid-range primes (149 to 65537), less at the very small end (fixed overhead dominates) and very large end (the inner FFT's own two process() calls inside the constructor start to dominate). No regressions in the existing tests. Committed as 78396b7.

[ejmahler]

Looks good. Thanks to @HEnquist for the submission and @awxkee for the feedback.