Problem: Search Path Location is not Reasonable when Embedding in Other Scripting Engines

As discussed in this PR with @slozier ( https://github.com/IronLanguages/ironpython3/pull/1957#discussion_r2187237100), we may want to fix how the Search Path (and any other applicable paths) are resolved when embedding in another scripting engine such as PowerShell.

Since, IronPython uses the executing assembly as the default location, embedding it in PowerShell with the Import-Module 'IronPython.dll' command causes the Search Path to resolve to PowerShell's installation directory. This doesn't seem like the intended behavior.

I'm opening this issue before working on a PR, as we may want to discuss how we identify when IronPython is embedded in a scripting engine first, so that we don't accidentally change the behavior for when IronPython is embedded in a regular application/used as a general shared library.

Obviously, detecting the usage of PowerShell-Specific namespaces and assembly locations may be one option, but we may want to explore others in case we want to address interop with other langs.

For the latter, we would also have to identify what those languages/engines might be. I think we have 2 options here:

• Scope this issue to CLR/C#-powered engines like IronRuby or any of the Microsoft languages like PowerShell/VB/ClearScript/etc
• Scope this issue to just PowerShell

Start with the linked pull request discussion and trace how the Search Path is resolved from the executing assembly when IronPython is imported into PowerShell. Compare the possible CLR-engine and PowerShell scopes described in the issue; done requires a decided scope and documented expected path behavior before implementation.