Resolve shell env API performance issue for single env approach

[anthonykim1]

Potential root of the performance cause:

1. Using diff approach where we check for change the environment variables, and only firing an event if there is a difference, should resolve the problem
2. O(n) - iterating through each environment variable in the process of fetching them (inside shell such as bash) is what is slow
3. Print statements in the above O(n) is what is causing the slowness (shell side: e.g. bash side)
4. O(n) - iterating through each environment variable when trying to calculate the diff is what is slow (in the shellEnvDetectionCapability)

Edit: d3ef701 brought back instant bash prompts. I think it was combination of printenv with compgen and tons of printf statements really slowing things down. So Mainly Scenario number 3 was correct

[anthonykim1]

https://github.com/user-attachments/assets/57167cc9-fd5b-424b-b302-83542592365d
@Tyriar This is for bash, but I think I brought back the perf to normal

[anthonykim1]

this allow us to only printf and send to VS Code if there is a difference in terms of value.

builtin printf '\e]633;EnvSingleEntry;%s;%s;%s\a' "$key" "$(__vsc_escape_value "$value")" "$__vsc_nonce"
below allow us to send to VS Code if it is a brand new variable.

[anthonykim1]

Because we now track a cached Map (two array because associate array are only supported in bash version 4.0 or above), we also need to make sure environment variable deletion gets accounted. Both in bash side and VS Code side.

If there is an environment variable that was cached before but not in user's environment variable list anymore, we need to detect that and update the map accordingly, and let VS Code know. (by something like EnvSingleDelete.. etc

[anthonykim1]

Although we have more loops now in the script, time is actually shorter because we use the least number of printf statement as much as possible, avoid using printenv, and compgen.

Check this by looking at the time calculation and just how things feel.