Enhance `startapp` Command for Nested App Creation and Correct `AppConfig.name` Generation

### Code of Conduct

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

### Feature Description

Enhance the `startapp` command to automatically create parent directories when a nested app path is provided, and to correctly generate the `AppConfig.name` attribute to reflect the full Python import path (e.g., `apps.blog` instead of just `blog`).

### Problem

Many Django projects, especially larger ones, organize their applications within a dedicated "apps" directory (e.g., `myproject/apps/blog/`). This approach improves project structure and maintainability by preventing the root directory from becoming cluttered with numerous app folders. Currently, however, Django's `startapp` command presents two significant usability issues for developers adopting this common pattern:

1. **Manual Directory Creation Requirement**: When attempting to create a new app within a subdirectory using `python manage.py startapp `, the command fails if the specified parent directory (e.g., `apps/`, `apps/blog/`) does not already exist. The developer is met with a `CommandError: Destination directory '...' does not exist, please create it first`. This adds an unnecessary manual step to the app creation process. Developers are forced to `mkdir` the parent directory before running `startapp`, which is an inconvenient and interruptive hurdle. This friction discourages adherence to a clean, nested app structure.

2. **Incorrect `AppConfig.name` Generation for Nested Apps**: When an app is generated at the root level (e.g., `python manage.py startapp blog`), the name attribute within `apps.py` correctly reflects the app's simple name (e.g., `name = 'blog'`). However, when `startapp` is used to create an app within a nested path (e.g., `python manage.py startapp blog apps/blog`), the `AppConfig.name` attribute still incorrectly defaults to just the app's immediate name (e.g., `name = 'blog'`). The correct value for a nested app like `apps/blog` should be `name = 'apps.blog'`, reflecting its full Python import path. This discrepancy forces developers to manually edit the `apps.py` file immediately after creation, a repetitive and error-prone task that can lead to subtle import issues or app loading problems if overlooked.

These problems collectively reduce developer efficiency and introduce unnecessary friction for a widely adopted project organization strategy.

### Request or proposal

request

### Additional Details

Current Workflow (Problematic):

1. Developer wants to create `myproject/apps/blog/`.
2. Developer runs `python manage.py startapp blog apps/blog`.
3. Command fails with `CommandError`.
4. Developer must manually run `mkdir apps` or `mkdir apps/blog`.
5. Developer re-runs `python manage.py startapp blog apps/blog`.
6. Command succeeds, creating `myproject/apps/blog/` and `myproject/apps/blog/apps.py`.
7. Developer opens `myproject/apps/blog/apps.py`.
8. Finds `name = 'blog'`.
9. Developer must manually change it to `name = 'apps.blog'`.

Desired Workflow (Proposed):

1. Developer wants to create `myproject/apps/blog/`.
2. Developer runs `python manage.py startapp blog apps/blog`.
3. Command automatically creates `apps/` or `apps/blog/` directory if it doesn't exist.
4. Command creates `myproject/apps/blog/` and `myproject/apps/blog/apps.py`.
5. Developer opens `myproject/apps/blog/apps.py`.
6. Finds `name = 'apps.blog'`.
7. No manual changes required.

This enhancement aligns with the principle of "batteries included" and significantly improves the out-of-the-box experience for structuring larger Django projects. It also prevents common configuration mistakes related to `AppConfig.name`.

### Implementation Suggestions

_No response_