Consider more informative guidance for customers trying to migrate code

[billti]

Rather than just 'identifier not found' (such as for trying to use an API from the old library that no longer exists), or 'syntax error' (such as for interpolated string changes), we could perhaps detect these cases and have a more helpful error message, perhaps redirecting to a page that lists the changes and how to migrate such code (or open an issue to request an API/feature).

[billti]

Lots of fun debate on this one. I think we still need to 'triage' further to come to agreement.

[filipw]

I vote for a compatibility layer (for missing library functions)

[swernli]

The @Unimplemented attribute was added to the language to help provide guidance on this, but does not allow for adding any extra text to the error. After discussion with @DmitryVasilevsky we landed at wanting support for an optional string that gets added to the error output. I'll work on that, and that should enable any additional libraries we want to add with guidance for users on what to use.

[swernli]

Diggin into this further, we hit some complications:

• Adding support of a string in the @Unimplemented attribute parameters would mean copying that string across AST->HIR, which makes some of the data structures non-Copy and interferes with the way they are being used. This can be fixed, but becomes a larger refactor that ideally would use Copy identifiers (like integers) to index into a cache of strings. At that point it just becomes a small implementation of string interning, which we have wanted to get across the compiler anyway, but shouldn't be done quickly for just one part of the code.
• APIs marked as unimplemented should be suppressed in completion lists, which will require an update to the language server to make it attribute aware when putting together the completion list.

Given that, the updated behavior we want for this doesn't seem reasonable to squeeze into 2401, so I'll remove the milestone tag.