Use mono_repo for package:web

[srujzs]

Splits package:web into two packages:

• package:web
• package:web_generator (not published)

The latter contains our tooling to generate the former, and used to be the tool directory.

• Refactors code to point to new paths (and using Platform.script.resolve so that the bin/ files can be run from anywhere instead of within that directory)
• Moves directories like third_party and tests to their new appropriate locations
• Moves CI configurations to mono_repo.yaml and mono_pkg.yaml files and is now generated as dart.yml (used to be build.yaml)
• Updates READMEs to reflect the package split
• Adds new LICENSE, pubspec.yaml, and CHANGELOG files
• Removes JSArrayExtension which is no longer needed.

Refactors code to point to new paths and moves directories like third_party to their appropriate locations. Moves the CI configurations to mono_repo.yaml and mono_pkg.yaml files, and is now generated as dart.yml.

[kevmoo]

But...why? What does this get us?

[srujzs]

This came up with analysis of an external PR. Analysis with the latest dev version has started failing due to the generator using JSArray.length and JSArray.[]. Since those members didn't exist until recently in dart:js_interop, we were using the declarations in util.dart. Once those members were added to dart:js_interop, it started using the definitions in the SDK instead implicitly because type members have higher precedence than extension members. However, when we added @Since annotations, analysis started to fail because the minimum SDK version of this package was not >=3.6. This will start turning CI red.

The solutions were:

• Update the minimum SDK constraint. This may be okay, but it doesn't make sense to require a later SDK version even though none of the code users can actually use is impacted. This probably also isn't the last time we'll need to do this.
• Disable analysis for the generator (temporary, but not tractable long term).
• Use extension overrides for every single usage of those JSArray members (bad considering there are like ~25 usages).
• Separate the generation code from the interop definitions (this PR).

As a bonus, if we wanted, we could publish the generator as a separate package so users can use it to generate definitions that we don't emit in this package. This was discussed in https://github.com/dart-lang/web/issues/145 before, but is not really the primary goal of this PR.