Add API parameter to cap thread usage

[aliddell]

• Adds a new API parameter to the settings struct, max_threads, which allows users to cap the number of threads used by the Zarr stream.
• Updates tests and examples to reflect.
• Updates the Python package version to 0.1.0.
• Updates the description of the Python package from "Python bindings for acquire-zarr" to "Performant streaming to Zarr storage, on filesystem or cloud"

[jeskesen]

LGTM.

Some small details:

• std::thread::hardware_concurrency() can return zero if it can't determine the number of cores. Should this case be handled?
• If a user sets a higher number than std::thread::hardware_concurrency(), it silently changes that value. a) should it let the user set a higher value if they want to? b) should there be at least a warning that the value is being changed, or an exception?

[aliddell]

LGTM.

Some small details:

* std::thread::hardware_concurrency() can return zero if it can't determine the number of cores.  Should this case be handled?

* If a user sets a higher number than std::thread::hardware_concurrency(), it silently changes that value.  a) should it let the user set a higher value if they want to?  b) should there be at least a warning that the value is being changed, or an exception?

We will allow the user to set a higher value, and interpret setting 0 as "maximum hardware concurrency." We'll warn only if we can't determine what that is.