Add optional --register flag to startapp

### Code of Conduct

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

### Feature Description

Add an optional --register flag to manage.py startapp that automatically adds the new app to INSTALLED_APPS in settings.py, when it's safe to do so.

### Problem

Right now, creating an app is two steps:

python manage.py startapp appname

...and then manually adding it to INSTALLED_APPS:

"appname.apps.AppConfig",

It's repetative to implement the second step. Its easy to forget the second step, or make mistakes and when you do, you get a confusing error.

### Request or proposal

proposal

### Additional Details

python manage.py startapp appname --register

This creates the app as usual and automatically registers it in INSTALLED_APPS.

The edge cases:

1.Not everyone's settings.py looks the same.
2.Not everyone's app directory is placed the same.

Some projects split apps across multiple files, or build INSTALLED_APPS dynamically instead of writing it as a plain list. Apps can also live in different places relative to the project root, so the dotted path Django needs (appname.apps.AppConfig vs. myproject.appname.apps.AppConfig, for example) isn't always the same either.

So the flag should only act when it can be sure it's safe. If it can't confidently find a plain list to edit, or can't confidently work out the right dotted path for the app, it should just fall back to today's behavior.

The existing behavior of startapp stays completely unchanged when the flag isn't used.

### Implementation Suggestions

Resolve the settings module the same way Django already does, through DJANGO_SETTINGS_MODULE.

Parse the settings file with Python's ast module, not regex or exec, looking for a module level assignment INSTALLED_APPS = [...] or (...) made up of string literals. If it's not a plain list or tuple like this, treat it as unsupported and fall back.

Work out the app's dotted import path from where it was actually created, using the same logic startapp already uses to name the app (the destination directory passed to the command, or the current directory if none was given) rather than assuming it's always a top level package. If that path can't be resolved cleanly, fall back.

If both the settings list and the dotted path are resolved with confidence, insert the new entry as a new element, editing only that part of the file so existing formatting and comments are left alone.

If either check fails, don't touch any file. Just print the same reminder message startapp already gives today.

Start at the manage.py startapp entry point and trace how it resolves the destination, DJANGO_SETTINGS_MODULE, and its existing reminder. Use the stated ast-based plain-list or tuple checks to define the safe path, then verify that unsupported settings or unresolved app paths leave files unchanged while a confident case adds the app entry and preserves existing formatting.

Written by the indexing model from the issue text.