removed on language activation events and switched to a more specific event

[ashishchoudhary001]

Reason for this change is captured in the GitHub Issue: 228

Though at the moment the extension gets activated on a variety of events...but if we remove other activation events the extension will be activated when:
Workspace contains a file/folder ending with .portalconfig at any level of depth.

Tested with this change (and removing other activation events):

[Tyriar]

@davidjenni I just looked at the activation time after installing the extension on my 11th gen alderlake CPU and for 4 reloads it was:

579ms
741ms
607ms
546ms

This is time that the extension host is busy loading your extension, if you were using * this would be quite alarming. Since you're using onStartupFinished this impacts off the top of my head:

• CPU/battery usage to load all the code that may not ever by used
• RAM usage, which may make VS Code look bad (it's hard to measure this)
• Other onStartupFinished extensions may have deferred loading, depending on the order they are loaded
• This time could block early language server requests, or any extension host request for that matter (this is even more important for remote connections)
• This applies to all extensions hosts (typically just 1 if you only use a local window)

I wouldn't say this is a major issue, but imo the extension is not being a good citizen by having this catch-all activation event. I personally disable all "heavy" extensions like this to avoid death by 1000 papercuts.

When this topic came up in our standup just now some people called out extension uninstall hooks. You could install to PATH on first activation and then remove it via the uninstall hook.