Setup for unmanaged models in tests

### Code of Conduct

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

### Feature Description

A way to prepare the database in test so that unmanaged models can be created and referenced.

### Problem

The problem is that Django unmanaged models are useful to model certain edge cases (like 2 projects sharing the same DB) but are not well supported, and thus require custom code/setup to properly use them.

An example issue is having a managed model with a foreign key to an unmanaged model.
This is not easily fixed by custom `setup` in tests as because Django runs migrations right away after creating a test DB and those migrations fail if the referenced table is not already existing.

Existing patterns are:
- Set models as managed, but skip migrations in production with migrate `--fake`.
This works but requires manual management of migrations to flag which ones are to be faked on which do not.
This can also trick developers into thinking this model is managed an therefore can be updated.
- Move unmanaged models in a separate Django app; set them as managed; disable those app migrations in prod through `MIGRATION_MODULES`
Similarly, as above, this has a bad discoverability, especially when onboarding new devs.
- Conditionally set models to managed.
This requires custom code that is hard to maintain. Any changes in Django may break this and make it no longer viable.
Additionaly, if this requires generating different migrations for test and prod, it might require manual file system cleanup.

### Request or proposal

request

### Additional Details

An example application would be:
Immagine 2 docker applications connected to the same DB.
- One that manages books by listening to publishers and populating a book table.
- The other manages book reviews, where users registers, can list "registered" books and add their reivew.
Those are 2 different docker images, so they can't be 2 different Django apps on the same project.

### Implementation Suggestions

A possible approach is expanding `managed` to support an enum.
For example devs could set a model to `managed=Dev`. This will create migrations where the table is actually handled only in dev/test environments.

No file or test is named. Start by tracing Django's migration and test-database setup for unmanaged models, then review how foreign keys to unmanaged models are handled. Done would require an agreed mechanism for preparing referenced tables in tests without treating those models as production-managed, along with coverage for the proposed behavior.

Written by the indexing model from the issue text.