Improve CSV Reader Benchmark Coverage of Small Primitives

[tustvold]

Which issue does this PR close?

Closes #.

Rationale for this change

As we look to make changes to both the CSV reader itself (#4795) and the way that values are parsed (#4785) having good benchmark coverage is really important. Whilst reviewing #4795 I noticed an oversight in the benchmarks I added in #3357. In particular the parsers are tested with values sampled from the entire range of primitives. It is fairly common for CSVs to contain primitives on the order of thousands, not trillions, and so we should have benchmark coverage for this case.

On my local machine we can see the difference this makes

4096 i32_small(0) - 4096
                        time:   [78.292 µs 78.340 µs 78.390 µs]
4096 i32(0) - 4096      time:   [137.50 µs 137.95 µs 138.39 µs]

4096 u64_small(0) - 4096
                        time:   [81.071 µs 81.153 µs 81.244 µs]
4096 u64(0) - 4096      time:   [146.21 µs 146.36 µs 146.51 µs]

4096 i64_small(0) - 4096
                        time:   [101.31 µs 101.44 µs 101.59 µs]
4096 i64(0) - 4096      time:   [162.49 µs 163.03 µs 163.63 µs]

4096 f32_small(0) - 4096
                        time:   [128.87 µs 129.04 µs 129.18 µs]

4096 f32(0) - 4096      time:   [157.81 µs 157.88 µs 157.95 µs]

What changes are included in this PR?

Are there any user-facing changes?

[alamb]

This makes sense to me given in CSV world, the cost of parsing is related to the number of digits in the textual representation.