Add `--allow-redefinition-line-heuristic`, which would allow force-redefining in all cases

Feature

Right now, --allow-redefinition only allows redefinitions in cases of blocks on the same level.
If I understand it correctly, it is hypothetically possible to extend it to work on different block levels, as long as redefinition is a superseding block.
However, why not try something simpler? Instead of worrying about blocks, let's say that x: int # mypy:force or # mypy:manual means "x has a type int from this line onward, up until it's explicitly redefined again or goes out of scope (meaning function ends)".

Pitch

The problem with adding typing to dynamic language is that there are things like redefinitions - things that are not compatible with static typing out of the box. mypy proposes some ways of working around, e.g. muting such problems on a case-by-case basis. The big problem here, however, is that redefinition cannot be "fixed" by single comment or annotation - we have to add #mypy:ignore to every place the redefined symbol is used.

The another way of "fixing" is to actually fix them - but the thing with redefinitions is that they happen in Python is because they are convenient. Even some static languages add support for them (Rust wink wink). Removing them require code refactoring, and often adding more variables, which can lead to silent bugs (i.e. accidental use of old name). This is feasible only on a small scale, or with highest quality code, not on a big & diverse codebase.

The proposed solution is definitely wonky, but actually it provides a way to "fix" all redefinition-related issues without modifying the code and without sprinkling every line with #type:ignore.

From the moment user opt ins with mypy:force, they are basically responsible for manually annotating this symbol's type. This sounds bad but it's actually what we want - mypy cannot manage this variable's type anyway after all.

Start by reviewing the existing --allow-redefinition behavior and the issue's proposed line-based force/manual semantics. Determine how scope ends at function boundaries and how explicit redefinitions should be handled; the work is done when the new option consistently permits the described cases without requiring ignores at each use.