Own retained executable_name in ParseCommandLineFlags

[stanbot8]

In src/benchmark.cc, update ParseCommandLineFlags to own and refresh a copy of argv[0] on each call, ensuring BenchmarkReporter::Context::executable_name doesn't depend on caller-owned storage. Since benchmark::Initialize calls ParseCommandLineFlags, remove the redundant copies from the Python and Rust bindings (bindings/python/google_benchmark/benchmark.cc and bindings/rust/src/rust_api.cc).

Tests:

• Check reported values after repeated benchmark::Initialize calls, input mutation, and buffer destruction.
• Check the returned arguments and context.executable after repeated google_benchmark.initialize calls.
• Run python -I bindings/python/initialization_test.py in CI.

Codex reviewed and assisted with writing tests.

[LebedevRI]

Why?

[stanbot8]

Hi @LebedevRI. Currently, calling google_benchmark.initialize() again with a different executable name still returns the first name and uses it in benchmark JSON reports.

This change makes ParseCommandLineFlags own and refresh the executable name on every call. Python and Rust use that owned value, so their separate copies of the name are removed.

[LebedevRI]

Hi @LebedevRI. Currently, calling google_benchmark.initialize() again with a different executable name still returns the first name and uses it in benchmark JSON reports.

Ok, but why are you doing that? That function is only meant to be called once.
This isn't fixing a bug, it's completely changing it's semantics.

This change makes ParseCommandLineFlags own and refresh the executable name on every call. Python and Rust use that owned value, so their separate copies of the name are removed.

[stanbot8]

I came across this while running benchmarks in a Jupyter notebook. Since both runs share the same kernel, the JSON report for the second script still had the executable name from the first script.

I initially changed just the Python binding but noticed Rust had a similar workaround, so I expanded the change into ParseCommandLineFlags to avoid duplicating logic and having each binding handle its lifetime separately.

If you'd prefer, I can narrow this to just the Python binding

[dmah42]

why do you need to reinitialize across the notebook? what functionality do you lose by initializing once and then registering/running different benchmarks in each cell?