Default permission names

### Code of Conduct

- [x] I agree to follow Django's Code of Conduct

### Feature Description

Create a setting that allows you to customize the permission names that are used in a project.

Also, includes a management command that allows you to configure this setting in an existing site, shut the site down, run the management command to migrate permission names, and start the site back up with the new permission names.

### Problem

Django and Django Rest Framework differ on the way they refer to views. Django has `list`, `add`, and `change`. Django Rest Framework uses CRUDL which has `create`, `retieve`, `update` (which can also be a partial update), `destroy` and `list`.

In a DRF package of ours we decided it would be good to have the permissions names in Django be CRUDL, so we came up with this:

| Django | Django Rest Framework | |
| --------- | --------------------------- | ------------- |
| add_ | create_ | changed |
| change_ | update_ | changed |
| view_ | read_ | changed |
| | list_ | new |
| delete_ | delete_ | unchanged |

In order to do this however, we had to patch Django in a couple places. The patch needed to be applied in settings, because that seemed to be the only place that would patch Django early enough, so that all permission names from the start of the project would use the permission names we wanted. This also needed to happen early enough, so that migrations would use the new permission names.

The problem is that when we use this DRF package to create a new project, we need to remember to add the patch into the settings. And patching Django is unfortunate. So, I thought maybe it might be better if this was just built into Django.

### Request or proposal

proposal

### Additional Details

The code, tests for both the setting and management command, and docs have already been written. But I still need to put it through a real world test, where we disable the patch in our project and try the setting instead. I just haven't had time to do this yet.

### Implementation Suggestions

The docs written for the setting are probably a good explanation of the implementation that exists. The code needed to be altered in `django/contrib/auth/__init__.py` > `def get_permission_codename` and `django/contrib/auth/management/__init__.py` > `def _get_builtin_permissions` and `def rename_permissions_after_model_rename`.

---

.. setting:: AUTH_PERMISSIONS_MAP

``AUTH_PERMISSIONS_MAP``
--------------------------------

.. versionadded:: 6.2

Default: ``{}``

A dictionary mapping built-in permission action names to custom names. This
affects both the permission codename stored in the database and the
human-readable permission name.

For example, to use CRUDL naming conventions instead of Django's defaults::

AUTH_PERMISSIONS_MAP = {
"add": "create",
"change": "update",
"view": "read",
}

With this setting, a model ``MyModel`` would have codenames
``create_mymodel``, ``update_mymodel``, ``read_mymodel``, and
``delete_mymodel`` instead of the defaults ``add_mymodel``,
``change_mymodel``, ``view_mymodel``, and ``delete_mymodel``.

Note that "list" is not one of Django's default permissions. To include it,
set :attr:`~django.db.models.Options.default_permissions` in your model's
``Meta``::

class MyModel(models.Model):
class Meta:
default_permissions = ("create", "read", "update", "delete", "list")

.. note::

Changing this setting after permissions have been created in the database
will not automatically rename existing permissions. Run the
:djadmin:`renameperms` management command once to rename any permissions
already stored.

Start with get_permission_codename in django/contrib/auth/__init__.py and _get_builtin_permissions and rename_permissions_after_model_rename in django/contrib/auth/management/__init__.py. Review the existing setting, management-command tests, and documentation, then run the real-world test described by disabling the project patch and confirming that the setting and permission-name migration work together.

Written by the indexing model from the issue text.