[web]: update how flutter web builds its sdk artifacts

[sigmundch]

Currently flutter web uses a mix of approaches to build its SDK artifacts, which are different than what's done in the Dart SDK repo and our internal build systems. We would like to align them.

This includes the following small changes:

• Build DDC artifacts using the compile_platform script instead of the kernel_worker. Technically the output of both tools is supposed to be the same, so this part of the change is only for consistency/tech debt.
• Replace dart2js artifacts and include dart:ui. Today flutter web ships the artifacts from the Dart SDK. All dart:* libraries in the Dart SDK are shipped as a kernel binary file. Whereas dart:ui and dart:_engine are shipped as source. This pushes the cost of compiling these libraries to the client. This may not be noticeable to users, but it feels wasteful and inconsistent with what we do elsewhere since are doing this effort on every single build of a flutter web application in the wild.

There are two things worth noting:

• Until recently, the compile_platform script didn't support specifying a second library as an input, as a result this was not possible before. We have fixed that in dart-lang/sdk@14fa941
• Flutter web still offers 3 variants of the SDK (html, canvaskit, autodetect) and chooses among them using const-fromEnvironment expressions. When compiling to kernel we may need 3 .dill files, one per configuration where those const expressions are evaluated according to the 3 variants. Technically, we could work with a single .dill file and leave those expressions unevaluated as well, but this may be in conflict with future plans of the dart2js team. While dart2js supports unevaluated constants today, but we are in the process of changing that to front-load constant evaluation. Doing so will allow us to leverage more modular analyses in the future.

[yjbanov]

This is done enough. Whatever work remains, let's file more specific issues.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.