Add support for deprecating an export of a symbol

[natebosch]

In order to move definitions between libraries we sometimes use an incremental state where you can use either the old or the new import. The class/method may not be deprecated entirely, but we'd want to push towards getting it from the new import. If something is available through two imports and only one is deprecated there shouldn't be a diagnostic.

We've discussed this recently, but I couldn't find an existing issue so filing one now to gather discussion.

[natebosch]

This is likely a blocker for a feature like #44892 - we'd need the deprecation to trigger a diagnostic.

I think the unused imports diagnostic is already smart enough to understand when all the symbols from one import are also available from another. If that's the case we'd want to make sure it's not suggesting the deprecated import paths.

[lrhn]

See also: #23067

[natebosch]

Ah, I thought I had recalled another issue but didn't search long enough. Closing as a duplicate.