Remove dynamic type

### Proposal

Dart should remove the `dynamic` type for stricter type-safety, better performance and less support for bad practices.

### Justification

The use of `dynamic` is a bad practice, often even referred to as such in the documentation:
- "`dynamic`: Indicates that you want to disable static checking. Usually you should use `Object` or `Object?` instead." (https://dart.dev/language/built-in-types)
- "Dynamic calls are treated slightly different in every runtime environment and compiler, but most production modes (and even some development modes) have both compile size and runtime performance penalties associated with dynamic calls." (https://dart.dev/tools/linter-rules/avoid_dynamic_calls)

However, there are ways to bypass `dynamic` calls and implicit casts for your own projects using lints (e.g. with strong-mode).
But this does not solve the problems that the support for `dynamic` has for the Dart language in general.
Firstly, it results in worse performance of the compiled code, since more inefficient runtime checks are required. (I'm not an expert on Dart compilers, so correct me if I'm wrong on this point).
Secondly, the support of `dynamic` prevents other features that many developers would like to use in a type-safe object-oriented language. For example, `private`, `protected` and `public` modifiers are not possible because they could not support `dynamic` types except through very inefficient runtime checks (dart-lang/sdk#33383).

In general, Dart tries to be as type-safe as possible. But on the other hand there is this relict `dynamic`, which stands against it.
`dynamic` generally feels like a concession to JavaScript developers to get more of them to switch to Dart/Flutter. Developers who have moved from Java/Kotlin/Swift/C++,... are just disturbed by `dynamic` and it also doesn't bring any benefits except more opportunities to apply bad practices.

### Impact

All code that currently uses `dynamic` would have to be changed to `Object?` or subtypes and implicit casts would be required. Also, method calls would no longer be possible without knowing the type of an object.

### Mitigation

Since this would be a null-safety level change, it would have to be made optional at first and fully introduced with the next major release.