Incorrect value of sys.executable in dotnet tool IronPython.Console

Description

When IronPython console executable is installed as a dotnet tool, the value of sys.executable is path to ipy.dll rather than ipy.exe (or ipy on POSIX systems), which is the executable that has been run. The value of sys.executable is used by some Python code to recursively run Python in a subprocess.

This issue exists regardless whether the tool was installed as global, or into a dedicated directory through --tool-path.

When the tool is installed as a project tool, there is no executable available (as far as I know) and the program has to be invoked through dotnet, e.g. dotnet ipy or dotnet tool run ipy. Hard to say what should be a correct value of sys.executable in such a case. Perhaps IronPython could create a launcher script on the fly and report that script.

Note that the value of sys.path is correct (i.e. it contains subdirectories of the directory containing ipy.dll).

The example below is for Windows, but it is the same behavior on other OSes.

Steps to Reproduce

On Windows + PowerShell:

1. dotnet tool install ironpython.console --global
2. ~\.dotnet\tools\ipy.exe -c "import sys; print(sys.executable)"

Expected behavior:

Output:
C:\Users\USERNAME\.dotnet\tools\ipy.exe

Actual behavior:

C:\Users\USERNAME\.dotnet\tools\.store\ironpython.console\3.4.1\ironpython.console\3.4.1\tools\net6.0\any\ipy.dll

Version Information

IronPython 3.4.1 (3.4.1.1000)
[.NETCoreApp,Version=v6.0 on .NET 6.0.25 (64-bit)]

Microsoft Windows [Version 10.0.22631.2715]

Start with the IronPython.Console entry point and reproduce the dotnet tool commands using the reported ipy.exe, ipy.dll, and dotnet ipy invocations. Trace how sys.executable is selected for global, --tool-path, and project-tool installations; done means its behavior is corrected or explicitly defined for each supported case and verified on Windows and POSIX systems.