Django-taggit

~~~~~~~~~~~~~~~~~~

* Fix the package metadata to properly reflect the right Django and Python version requirements
Release 5.0.0 improperly stated its Django bounds as >=3.2, so people installing without bounds will end up on a version that won't work.

~~~~~~~~~~~~~~~~~~
* **Backwards icompatible:** Rename the (``content_type``, ``object_id``) index on ``TaggedItem``.
It is very unlikely for this to affect your code itself, and a migration will rename the index. This should not cause any downtime according to my research (Postgres does not lock the table for index renames, and Oracle holds a tiny lock to do it, and the change is only to the metadata, so is not dependent on table size).

* **Backwards incompatible:** Remove the ``.indexed_together`` and ``.unique_together`` attributes on ``TaggedItem``

We are instead using ``constraints`` and ``indexes`` to set up these properties.
* Remove support for Django 3.2.
* Remove usage of deprecated APIs for Django 4.2
* Remove support for Python 3.7 (no code changes involved)
* Fix ``tag_kwargs`` and ``TAGGIT_CASE_INSENSITIVE=True`` discrepency.

~~~~~~~~~~~~~~~~~~
* Remove Python 3.6 support (no code changes occurred, but we no longer test this release).
* Remove Django 4.0 support (no code changes occurred, but we no longer test this release).
* Add Django 4.2 support.

~~~~~~~~~~~~~~~~~~

* Add Python 3.11 support (no code changes were needed, but now we test this release).
* Add Django 4.1 support (no code changes were needed, but now we test this release).
* Fixed an issue where object caches would not be properly cleared after updating tags, leading
to stale reads in cases where ``prefetch_related`` is used.
* Change ``TagListSerializerField`` to be a subclass of ``ListField``. This should improve support for API document generation. This change should not affect API behavior, but might affect metaprogramming code, so please procede carefully during this update.

~~~~~~~~~~~~~~~~~~

* **Backwards incompatible:** Tag slugification used to silently strip non-ASCII characters
from the tag name to make the slug. This leads to a lot of confusion for anyone using
languages with non-latin alphabets, as well as weird performance issues.

Tag slugification will now, by default, maintain unicode characters as-is during
slugification. This will lead to less surprises, but might cause issues for you if you are
expecting all of your tag slugs to fit within a regex like ``[a-zA-Z0-9]`` (for example in
URL routing configurations).

Generally speaking, this should not require action on your part as a library user, as
existing tag slugs are persisted in the database, and only new tags will receive the
enhanced unicode-compatible slug.

If you wish to maintain the old stripping behavior, set the setting
``TAGGIT_STRIP_UNICODE_WHEN_SLUGIFYING`` to ``True``.

As a reminder, custom tag models can easily customize slugification behavior by overriding
the ``slugify`` method to your business needs.

`` Drop Django 2.2 support.

~~~~~~~~~~~~~~~~~~

* Add Python 3.10 support.
* Add Django 4.0 support.
* Drop Django 3.1 support.