The "base" keyword requiring subclasses to also use "base/sealed/final" is inconvenient for testing purposes

Currently when a class is marked as "base", subclasses need to also be marked as such (or be sealed/final).
While the logic makes sense, it puts a significant burden on the syntax.

As a package author, I have a few use-cases where an abstract class would benefit from being "base" to prevent mocking mistakes.

TL;DR, instead of:

```dart
// from my package
abstract class Base {}

// in user code:
class Example extends Base {}

// Incorrect test code:
class ExampleMock with Mock implements Example {}
```

They should do:

```dart
class ExampleMock extends Base with Mock implements Example {}
```

Such that this mocks methods introduced by `Example` but not the one from the `Base` class.

The issue is:
- Only a minority of users need to mock such a class.
But if `Base` was marked with "base", all users would have to make their subclass of `Base` with `base/final/sealed` – even if not necessary.
This adds a cost to the majority of for a minority of cases
- There is a clear solution, and the mistake only happens during testing.
As such, not using the `base` keyword doesn't hinder production

So as a package author, I'm in a weird conundrum. On one side, that keyword would help users spot their mistake more naturally due to writing `class ExampleMock with Mock implements Example {}` now being a compilation error.
On the flip side, the gain is too niche to justify asking everyone to modify all their subclasses.

I'm not sure what the solution would be, as I understand subclasses are required to use a keyword. We probably want to avoid cases where a class _looks_ like it could be implemented, but can't due to a transitive superclass being "base".

Start by reviewing the issue's `base`, `sealed`, and `final` subclass examples and the stated mocking use case. Determine whether the language rules can support the proposed exception without making implementability misleading; done requires an agreed solution and corresponding language specification changes, but no files or tests are named here.

Written by the indexing model from the issue text.