WIP-Path Update for Package installation

[theJasonHelmick]

On Windows, when a user installs a tool using a package manager like WinGet or Chocolatey in
PowerShell, the tool is often added to the system or user PATH environment variable. However,
changes to PATH made during the installation process are not automatically propagated to running
PowerShell sessions or other active console applications. As a result, users frequently need to
start a new PowerShell session to recognize and use the newly installed command-line tools.

This behavior can be confusing and disrupts the workflow—especially in automation scenarios or when
users expect tools to be immediately available post-installation. Addressing this limitation would
improve usability, align with user expectations, and reduce friction in both interactive and
scripted environments.

[iSazonov]

Why not just read the environment variables from the registry before launching a native application?
PowerShell executes a lot of code to run a native application so reading two keys of the registry will be unnoticeable in time.
This will address any changes to the environment variables (although we can limit ourselves to PATH only).
Example from Chocolatey

[daxian-dbw]

Superseded by #391

[daxian-dbw]

@iSazonov There are scenarios where the process-scope PATH is intentionally altered to restrict what PowerShell can discover for native commands.