IconPacks seem to look in the "current directory." - Solved.

**Describe the bug**
I have a somewhat unique situation: My WPF application is not an EXE, but is a WFP DLL that exposes a COM Interop method that displays a MetroWindow. This is due to the fact that the app is acting as a MAPI Client.

Long story short: Win32 Native C++ DLL that registers as a MAPI Client and then is configured as the "default MAPI client" to handle MAPISendMessage() and MAPISendMessageW(). Win32 Native C++ DLL then Invokes COM Interop method that displays said MetroWindow. (The Win32 Native DLL portion as well as WPF with MahApps.Metro + MetroWindow is already working just fine).

Before attempting to use an IconPack everything seemed to be working fine. After adding an Icon pack I receive the following error:

```
Could not load file or assembly 'MahApps.Metro.IconPacks.Material, PublicKeyToken=0c0d510f9915137a' or one of its dependencies. The system cannot find the file specified.
```

I have read the **Troubleshooting** section of the guide that recommends rebuilding the solution. However, I don't believe this is the issue. With my unique situation this "plugin" WPF app gets invoked by another host application (since it is acting as a MAPI Client). Therefore the "current executing directory" is that of the host application/process (my code is installed to c:\program files (x86)\ACMECompany\MAPIWidget and the invoking application is installed in c:\program files (x86)\ABCSoftwareCompany\Application).

I've wrapped the invoke method inside my native Win32 DLL to capture the .NET stack trace upon attempting to invoke the .NET side via COM/Interop:

I've ensured that all of the dependent assemblies are packaged with the MSI installer and do get installed along side my assemblies (and Win32 Native DLL) during the installation.

As a bit of a test I tried copying the following MahApps.Metro.IconPacks assemblies to the primary host application's c:\program files (x86)\ABCSoftwareCompany\Application path and things work:

```
MahApps.Metro.IconPacks.Core.dll
MahApps.Metro.IconPacks.Material.dll
```

(I'm only using a single Icon Pack).

Only after copying those assemblies to the invoking applications path does my Window load without exception.

How does MahApps.Metro and MetroWindow "know" where to look for the IconPack assemblies and their dependencies? Is there a way to have them "look" in the same path of the WPF assembly that is using them vs. having them "look" in the current executing application's path?

I've had other thoughts for a work-around: Register those assemblies in the GAC (not a super great solution as it forces them to be system wide - plus my initial tests with doing so have not worked - at least I believe I've configured the MSI to register in the GAC - I need to do further testing/research).

**To Reproduce**
Steps to reproduce the behavior:
1. Build a COM InterOp Assembly with WPF & MahApps.Metro + an Icon Pack
2. Create a native Win32 DLL that implements MAPISendMessage() and invoke COM Interop exposed method on .NET assembly mentioned in step1.
3. Build MSI install (Basic Setup Project - Visual Studio 2022) that installs both the Win32 Native DLL and the .NET WPF Assembly (and dependencies) to c:\program files (x86)\Company Name\Product Name, register the .NET Assembly for COM, create a few registry keys to setup the Win32 Native DLL as the default MAPI client.
4. Run the "invoking application" that will call upon MAPISendMessage() that invokes the Win32 Native DLL that invokes the .NET assembly via COM Interop.

**Expected behavior**
The icon packs to be found and work.

**Screenshots**
Screenshot of MessageBox rendered by Win32 Native DLL provided above.

**Desktop Environment (please complete the following information):**
- IconPacks Version: Originally tried 6.2.1.0 and downgraded to 6.0.0.0 (with same results)
- Visual Studio: [e.g. 2022 17.14.20]
- .NET Framework: [e.g. 4.8]

Reproduce the issue through the native Win32 DLL's MAPISendMessage() path and its COM Interop call into the WPF assembly installed under the product directory. Compare assembly loading when MahApps.Metro.IconPacks.Core.dll and MahApps.Metro.IconPacks.Material.dll are beside the host application versus beside the WPF assembly. Done means the icon packs load in the described installed configuration without copying them into the host application's directory.

Written by the indexing model from the issue text.