Allow customization of returning_fields in bulk_create

### Code of Conduct

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

### Feature Description

Improve the way and allow more control over which fields are returned back from the database when using `bulk_create`.

### Problem

On databases that support `INSERT ... RETURNING` (all but MySQL), `bulk_create` will use it to retrieve the values of generated columns of the inserted rows. "generated columns" currently being `AutoField` and `GeneratedField`. These are marked using `db_returning = True`.

This is sufficient for standard uses of `bulk_create`, because the data being inserted is not changed. However `bulk_create` supports a parameter named `update_conflicts`. In case `update_conflicts` is used, not all objects given to `bulk_create` may be inserted. Some of them may instead update existing rows.
As a result, when `update_conflicts` is used, one cannot rely on _any_ of the values (except those in `AutoField` and `GeneratedField`) present on the objects returned by `bulk_create`. For rows that were updated, the values would not match the data now present in the database, they would match the values that were _supposed_ to be inserted, but had a conflict.

When using `update_conflicts`, the primary key should be returned no matter if it is an `AutoField` or not, this way the returned objects will have the correct primary key set on them, whether they were inserted or updated.

I would also propose adding another parameter to `bulk_create` (e.g. `returning_fields`) to let users specify additional fields Django should fetch using `INSERT ... RETURNING`. This way users can specify additional fields that they need to be up to date in the returned objects when using `update_conflicts`.

### Request or proposal

proposal

### Additional Details

_No response_

### Implementation Suggestions

Having looked at the code the implementation already supports most of the required machinery.
`bulk_create` uses `_batched_insert`. `_batched_insert` will collect the fields to be returned from `model._meta.db_returning_fields` (which will contain any `AutoField` and `GeneratedField`).
As far as I can tell all that is needed for this feature would be to update this to the logic described above instead of limiting it to `AutoField` and `GeneratedField`.