Split View into BaseView and AsyncView

### Code of Conduct

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

### Feature Description

Split Django's class based `View` into dedicated sync and async base classes: a shared `BaseView`, the existing `View` for sync, and a new `AsyncView` for async. The current `view_is_async` flag and runtime introspection would no longer be needed on the new `AsyncView` path.

### Problem

`View` tries to cover both sync and async in one class, deciding which mode to use by the view_is_async flag. This leads to several problems:

- A single class with two contracts
- Typing is inaccurate. Signatures collapse into sync/async unions, so type checkers and IDEs cannot give correct hints
- Decorators must branch on view_is_async or iscoroutinefunction at runtime rather than targeting a concrete class
- Third party libraries need markcoroutinefunction to make their wrappers behave correctly

### Request or proposal

proposal

### Additional Details

- `BaseView`: holds all shared logic
- `View`: the sync view, inherits from `BaseView` (without any backwards-incompatible changes)
- `AsyncView`: a pure async view, also inherits from `BaseView`

No impact on existing code, but enables pure async views for new code and a smooth migration path for the old one. Low maintenance cost for the core team (much less than the existing view), and it solves a real problem. I don't see a reason not to do it.

Benefits:

- Clear contract for users: pick sync or async, no flags
- Accurate typing for both sync and async paths
- Cleaner decorator behavior, no runtime branching on async-ness
- Easier for third party libraries
- Removes a class of subtle bugs from mixed sync/async method definitions.

### Implementation Suggestions

_No response_

Start by tracing Django's existing View implementation and the view_is_async flag to understand the shared behavior and current sync/async contract. Compare the proposed BaseView, View, and AsyncView responsibilities, then verify that existing sync behavior remains compatible while the new async path has a clear pure-async contract.

Written by the indexing model from the issue text.