libomp workaround for Linux, Mac

[swernli]

This adds a workaround for loading of the libomp library in Linux and Mac. Since we now bundle the libomp.[so|dylib] with our simulator in the dotnet package runtimes folder, we shouldn't need the host to install that library manually. However, Linux and Mac do not automatically use the folder of the active binary as an additional dynamic library search path, meaning load of libomp was still failing on those platforms if it was not already installed. By using an explicit invocation of an operation that comes from that library, we trigger logic in dotnet that will perform the library load while including the platform specific runtimes folder. As a result, when the simulator is loaded, it will find libomp already in memory and not need to perform any additional loads.

Note that this does not work on Windows because there the library has a different name (libomp140.x86_64.dll), but the Windows load library logic already finds this library so no workaround is needed there.

[swernli]

I was able to verify this fixes the issue by using an anaconda docker container (thanks @kuzminrobin for the pointers on that). When loading the qsharp and iqsharp packages without my fix, I get the failure we were seeing before:

Unable to load shared library 'Microsoft.Quantum.Simulator.Runtime' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: libMicrosoft.Quantum.Simulator.Runtime: cannot open shared object file: No such file or directory

With the fix, I get successful execution:

Hello, quantum world!
()

[swernli]

Unfortunately this causes a stand-alone build failure despite the e2e builds passing. I'm able to repro it locally and will get a fix soon.

[cgranade]

Looks great to me! We'll likely want to revert the change to IQ# that copies libomp.* from the NuGet packages into the conda packages as a part of applying this fix.