chore: Use Poetry as Commitizen version provider

Using Poetry as the version provider source will specifically get and set the
version using the `tool.poetry.version` field in `pyproject.toml`, as described
[here](https://commitizen-tools.github.io/commitizen/config/#version-providers).

This has two advantages:

1. We only have to keep track of the project version in one place in
`pyproject.toml`.
2. We avoid bugs that can result from the "naive" way that `cz bump` works when
using `version_files` instead of `version_provider`. When bumping the version,
it will replace all instances of the current version string in `pyproject.toml`
with the new version string.This can cause bugs when certain dependencies
coincidentally have a version constraint which contains the current version
string as a substring. When this happens, it results in an inconsistent state
between `pyproject.toml` and `poetry.lock`.

Here is an occurrence of this bug as reported by one of our users:

"""
I tried to bump the version of my project from 0.2.1 to 0.2.2, but `cz bump`
not only changes the `version = "0.2.1"` line under the [tool.commitizen]
heading, but also the version of a dependency called `kaleido`, which happens
to also be constrained to >=0.2.1, which causes it to error on the fact that
the `poetry.lock` isn't up to date with the `pyproject.toml` anymore, leaving
the project in an inconsistent state.
"""

{{ cookiecutter.__package_name_kebab_case }}/pyproject.toml

@@ -16,7 +16,7 @@ bump_message = "bump(release): v$current_version → v$new_version"
 tag_format = "v$version"
 update_changelog_on_bump = true
 version = "0.0.0"
-version_files = ["pyproject.toml:version"]
+version_provider = "poetry"
 {%- endif %}
 {%- if cookiecutter.with_typer_cli|int %}