Enhance many_cubes stress test use cases

[superdump]

Objective

• Make many_cubes suitable for testing various parts of the upcoming batching work.

Solution

• Use argh for CLI.
• Default to the sphere layout as it is more useful for benchmarking.
• Add a benchmark mode that advances the camera by a fixed step to render the same frames across runs.
• Add an option to vary the material data per-instance. The color is randomized.
• Add an option to generate a number of textures and randomly choose one per instance.
• Use seeded StdRng for deterministic random numbers.

[superdump]

I see we use fastrand in bevy_asset so I switched to that for reproducible random numbers, just to reduce adding a dependency.

EDIT: Then I saw that bevymark seemed to want to use seeded StdRng and that's built into rand that is already a dependency so I switched to that instead.

[alice-i-cecile]

Swapping to clap for CLI uses is nice: we should probably update our other examples to use it too.

[superdump]

Switched to google's argh crate for command line parsing. It's small, has only dependencies that we already have (syn, quote, serde, proc-macro2), and is still derive-based so brings most of the ergonomics we need. FromArgs has a blanket implementation for anything that implements FromStr. This means we have to implement FromStr for enums.

[robtfm]

looks fine and works as intended.

the logic for material selection is quite hard to follow. this is a stress test rather than a "guide" example so maybe not very important, but if i were going to be picky i would say it'd be clearer to initialize the materials upfront, then just use &materials[rng.range(0..materials.len())] in the pbr bundles.

as written, i think if you use 2 textures it will generate a new material for every cube - upfront init would also avoid that.

[superdump]

Good call. It evolved as I was adding individual features but I like your suggestion.