Gracefully handle obsolete migrations

[nex3]

The migrator is in a bit of a sticky place when it comes to migrations for (parse-time) behavior that has already changed in Dart Sass 2. Because the migrator uses Dart Sass as its parser, if Dart Sass starts to emit parse errors for a given deprecated syntax, new versions of the migrator won't be able to migrate it.

At the very least, we should mitigate this by having older migrations print messages directing users to the last version of the migrator that supported that migration. Ideally, we would do something even more clever like installing and running those older versions for a period of time after the breaking change lands (or just shipping them with the migrator). It's also possible that we could do some renaming and have multiple versions of the Sass parser coexist within the same process to continue supporting older migrations for a time.

We'll need to decide which approach to take and implement it before Dart Sass 2 releases.

[nex3]

Another option here would be to just keep the migrator on Dart Sass 1.x for a period of time after Dart Sass 2 releases. That only works as long as we don't need any migrations from Dart Sass 2-only syntax, though.

[jathak]

While something fancier that automatically downloads old versions would be nice to have, given our bandwidth constraints, I think just a message directing users to the old version is the right way to go. We can maintain a Dart Sass 1.x branch for any patches we need to make to obsolete migrators, but I think trying to keep things like the module system migrator on 1.x probably causes more problems than it's worth.