Consider making handleTerminalLink return a Promise

[alexr00]

Testing #101300

I was testing with the existing (albeit turned off) document link provider for issues in the GHPRI extension. I wanted to re-use as much code from the document link provider as possible. With the document link provider, resolveDocumentLink can return a promise. To keep a similar pattern I would also expect handleTerminalLink, so I can do any further information resolving there.

[Tyriar]

What would it return? I removed the old TerminalLink.target? property which could be filled in as I thought this was simpler.

[eamodio]

While, I'm not sure handleTerminalLink should return a promise, but I am a little worried about extensions not doing more intensive processing in provideTerminalLinks and instead delaying until handleTerminalLink, which as long as they provide some interaction that is probably fine, but if they don't it could make it seem that vscode is broken -- because I click on a link and nothing happens. Maybe it should return a boolean | Promise<bool> in which case we could show some interaction (or maybe just remove the link decoration from that range)?

[alexr00]

I would expect it to return Promise<void>. My testing was focused around sharing code between a document link provider and a terminal link provider, and I had made resolveDocumentLink async, which meant that I couldn't reuse some of that code in handleTerminalLink.

Regarding having more work done in handleTerminalLink: we already expect extensions to do that in resolveDocumentLink. We have already accepted that there could be work happening when someone clicks a link.