Benchmarking hangs if `with_inputs` function is slow relative to benched function

[Macil]

I notice that if you use a Bencher with a with_inputs callback that takes relatively much longer than the benched function, then running cargo bench hangs for a very long time. This happens to me frequently as I'm developing because I'll often implement the with_inputs callback first and want to test it before I have finished or started the benched function, or because I'll temporarily disable parts of the benched function to figure out which parts of it significantly contribute to the runtime, or because I legitimately am benchmarking a quick function that relies on an expensive-to-create value.

use divan::Bencher;
use std::{thread, time::Duration};

fn main() {
    divan::main();
}

#[divan::bench]
fn bench_test(bencher: Bencher) {
    bencher
        .with_inputs(|| thread::sleep(Duration::from_nanos(1)))
        .bench_refs(|_| ());
}

> cargo bench
Timer precision: 100 ns
udmf           fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ bench_test

If I make the with_inputs callback just return () instead of sleeping, I get this output with a very high iteration count. This makes me think the issue is that the iteration count is based on how long the benched function takes and not at all on how long the with_inputs callback takes, which means an obscenely high iteration count can be picked that results in too much time spent creating inputs.

Timer precision: 100 ns
udmf           fastest       │ slowest       │ median        │ mean          │ samples │ iters
╰─ bench_test  0 ns          │ 0.054 ns      │ 0.001 ns      │ 0.003 ns      │ 100     │ 6553600

[nvzqz]

I hadn't actually considered a no-op benchmark to be a legitimate scenario, but you make a good point about it making sense to have for initial benchmark code setup/testing.

I'd be happy to accept a PR that limits sample iterations to something reasonable.

v0.2 will introduce the option to set a maximum for sample iterations, which should default to the same number used to fix this in v0.1.