[extension types] Relax rule on representation/implements type relation (#3405)

Based on the discussion in #3397, this PR introduces a relaxation in the rule about the required typing relationship between the representation type `R2` of an extension type `E2` and an implemented extension type `E1` with instantiated representation type `R1`:

The existing rule requires that `R2` is a subtype of `R1`. The new rule includes the old rule, but also allows the situation where `R2` is a subtype of `E1`.

Example, allowed before and now:

```dart
extension type FancyWidget(Widget _) {
  // Something
}

extension type FancyListWidget(ListWidget _) implements FancyWidget {
  // Something
}
```

Example, allowed now (but used to be an error):

```dart
extension type FancyString(String it) implements String {
  // Something
}

extension type EvenFancierString(FancyString it) implements FancyString {
  // Something
}
```

The point is that this allows us to use the same idiom for superinterfaces that are extension types and superinterfaces that are non-extension types: Both `FancyString` and `EvenFancierString` use the following template:

```dart
extension type B(A it) implements A {}
```

Author: eernstg

accepted/future-releases/extension-types/feature-specification.md

@@ -15,6 +15,11 @@ information about the process, including in their change logs.
 [1]: https://github.com/dart-lang/language/blob/master/working/1426-extension-types/feature-specification-views.md
 [2]: https://github.com/dart-lang/language/blob/master/working/extension_structs/overview.md
 
+2023.10.25
+  - Allow an extension type to have `implements T` where `T` is a
+    supertype of the representation type (the old rule only allows
+    it when the representation type of `T` is a supertype).
+
 2023.10.18
   - Add error for non-covariant occurrence of a type variable in a
     superinterface.
@@ -1185,7 +1190,7 @@ representation type `R`, and that the extension type `V1` with
 declaration _DV1_ is a superinterface of _DV_ (*note that `V1` may
 have some actual type arguments*).  Assume that `S` is the
 instantiated representation type corresponding to `V1`. A compile-time
-error occurs if `R` is not a subtype of `S`.
+error occurs if `R` is neither a subtype of `S` nor a subtype of `V1`.
 
 *This ensures that it is sound to bind the value of `id` in _DV_ to `id1`
 in `V1` when invoking members of `V1`, where `id` is the representation