wasmparser: Optimize Locals::get type query

[Robbepop]

When looking through the code I saw that Locals::all field unnecessarily pushes all locals, even the ones that have already been covered in the first vector. This further slows down the binary_search call due to having to search through all the unnecessary indices.

This led to a modest speed-up of ~1-2% though I doubt that the current set of benchmarks really cover this scenario and therefore the gains might be higher for some real world Wasm files with many large functions.

I changed the types of MAX_WASM_FUNCTION_LOCALS and MAX_LOCALS_TO_TRACK because they are only used at those locations and the new typing no longer necessitates casts.

[Robbepop]

CI tests fail because this PR uses core::iter::repeat_n which got stabilized in Rust 1.82 but the MSRV of wasm-tools seems to be Rust 1.76. Shall I use the inferior (for performance) core::iter::repeat(..).take(n) approach or shall we bump the MSRV?

https://github.com/bytecodealliance/wasm-tools/blob/main/Cargo.toml#L89-L95

edit: For now I went with the repeat().take() approach since it is easily fixable once the MSRV bumps since there is a clippy lint for it.

[alexcrichton]

Thanks for this! I'll go ahead and flag this for merge.

As for MSRV, I'm not 100% sure how best to handle this. I feel that Wasmtime's 2-latest-rustc-version is a bit too aggressive for this repository given the broader use that's intended here. Freezing to just one version though is also something I don't think is tenable. I've roughly been thinking that "current - 10" is a reasonable enough window for this workspace, but I haven't set up automation or anything like that to such effect.

[Robbepop]

@alexcrichton thanks!

current - 10 roughly equals to a Rust version that has been stable for just over a year. Probably a decent foundation for such a widely used dependency.