Add progress option to ve_run

[davidorme]

Description

This PR adds a simple optional progress report to ve_run, so that something happens when the command runs and logging is being sent to file (which is likely all reasonable use cases).

When ve_run is executed with --progress, a user sees:

Starting Virtual Ecosystem simulation.
* Logging to: /tmp/ve_example/out/logfile.log
* Loading configuration
* Saved compiled configuration: /tmp/ve_example/out/vr_full_model_configuration.toml
* Built core model components
* Initial data loaded
* Models initialised: plants, animals, litter, hydrology, abiotic_simple, soil
* Starting simulation
100%|███████████████████████████████████████████| 24/24 [00:06<00:00,  3.52it/s]
* Simulation completed
* Merged time series data
* Saved final model state
VR run complete.

Fixes #402

There are probably more elegant ways of handling the tqdm progress bar, but tqdm is usually used with a for loop rather than while. We could explicitly loop over the known number of updates at the moment, but retaining the current while timing loop is a useful implicit reminder that updates might not always be synchronised.

Type of change

• New feature (non-breaking change which adds functionality)
• Optimization (back-end change that speeds up the code)
• Bug fix (non-breaking change which fixes an issue)

Key checklist

• Make sure you've run the pre-commit checks: $ pre-commit run -a
• All tests pass: $ poetry run pytest

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[davidorme]

Just spotted the VR in VR run complete.

[dalonsoa]

It looks good, but I don't really understand the reason for not using a for loop directly with tqdm, as usual, given that you know exactly the number of steps beforehand.

[davidorme]

I think we are using while because the original conception of the model had a kind of event stack - not everything happened on a synchronised tick with a fixed set of update times. I think that is something we may want to bring back in at some point. But ultimately, although a for loop would work better with tqdm here, I wanted to keep the changes simple.