Re-introduce Flutter SDK constraint upper-bound

[jonasfj]

At the Flutter 2.0.0 release it was determined that Flutter did not follow semantic versioning, and for this reason the upper-bound SDK constraint on Flutter should be ignored.

Hence,

name: mypkg
environment:
  sdk:     ^3.0.0   # This is the Dart SDK constraint
  flutter: ^3.20.0  # This is the Flutter SDK constraint

is currently re-interpreted as:

name: mypkg
environment:
  sdk:     '>=3.0.0 <4.0.0' # This is just expansion of the ^-constraint syntax
  flutter: '>=3.20.0'       # This is ^-constraint syntax + removal of upper-bound constraint.

---

Avoiding this re-interpretation of the Flutter SDK constraint would make it more consistent with the Dart SDK constraint. And in the scenarios where these SDK constraints are useful, it would allow package authors / application developers to use them.

Do note that when Flutter 4 is released, we might then have to do a trick similar to what we did around Dart 3, where we say that Flutter 4 still supports packages that have an upper-bound of <4.0.0 (but not packages that have <3.999.0).

To avoid compatibility issues we propose that we re-introduce the Flutter SDK constraint upper-bound by, either:

• (A) Letting it take effect for upper-bounds greater than the next Flutter version (3.24), OR,
• (B) Letting it take effect after language-version 3.5 (inferred from Dart SDK constraint).

[jonasfj]

Discussing this offline, it appears that while this could be a tiny improvement, it might not be worth the squeeze.

What we really want is probably more like:

name: mypkg
api:
  dart: 3.5.0 # indicating that we want the language version and API shipped in 3.5

Of course that leads down the road of designing API versioning.