Use ZIP file size metadata to allocate string

[MichaReiser]

Summary

We spend about 1.4% in VendoredFileSystem::read_to_string. Let's pre-allocate the string with the right size by using the zip file metadata
as a heuristic (don't trust it!)

Test Plan

cargo test

I verified that total spend in VendoredFileSystem::read_to_string goes down to 1.1% and it no longer shows up as a large contributor to malloc

[AlexWaygood]

Hmm. In #11863 (comment), you argued against doing this

[codspeed-hq]

CodSpeed Performance Report

Merging #13032 will improve performances by 8.11%

_{Comparing vendored-alloc-string-with-right-size (170ffb4) with main (a35cdbb)}

Summary

⚡ 1 improvements
✅ 31 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	vendored-alloc-string-with-right-size	Change
⚡	linter/default-rules[numpy/globals.py]	183.9 µs	170.1 µs	+8.11%

[MichaReiser]

Yeah, I now saw in the benchmarks (still need to verify that it helped) that I was wrong.

Reading through the code:

    fn read_to_string(&mut self, buf: &mut String) -> Result<usize> {
        default_read_to_string(self, buf, None)
    }

the last argument is the size hint... Oh well, it is None

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[AlexWaygood]

Thanks for explaining, sounds good!

(Is it worth adding a comment explaining the reasoning you just gave me?)