Deal with libiomp5 / libgomp conflict introduced by nGraph

Root of the conflict

It's generally unsafe to have two OMP implementations in the same process.
nGraph depends on libiomp5.so for several reasons, including:
- nGraph's LLVM-based JIT uses libclang's default OMP implementation, which is libiomp5.so.
- nGraph's bundled build of MKL and/or MKL-DNN is built/configured to depend on libiomp5.so, not libgomp.so.
In Ubuntu 16.04, MXnet indirectly depends on libgomp.so, via the Ubuntu-supplied version of libsoxr.so.0, via this dependence chain:
```
libopencv_core.so.2.4
libavformat-ffmpeg.so.56
libavcodec-ffmpeg.so.56
libswresample-ffmpeg.so.1
libsoxr.so.0
libgomp.so.1
```

In practice it's not possible:

Code compiled to assume libgomp.so sometimes depends on dynamic symbols not provided by libiomp5.so. See here
I can't remember if code compiled to assume libiomp5.so at runtime can be satisfied by the implementation provided by libgomp.so.
The Ubuntu-supplied libsoxr.so,0 is overly (IMO) dependent on libgomp.so: It stipulates the filename as well:
```
  $ readelf -d /usr/lib/x86_64-linux-gnu/libsoxr.so.0 | grep -i omp
   0x0000000000000001 (NEEDED)             Shared library: [libgomp.so.1]
```
Compiler / static-linker support for OMP library selection:
- GCC 5.4 (and maybe newer, I don't know) seems to generate code that requires libgomp.so specifically.
- Clang (at least current master, maybe earlier) is more flexible: It supports -fopenmp={libgomp|libiomp5}, and generates appropriate object code.

Custom build of libsoxr.so.0 that depends on libiomp5.so instead of libgomp.so
- I prototyped a hack of this, and it should work.
Modify nGraph's build system to let users specify which OMP implementation to use.
- Feasible in principle, since nGraph's build system builds most supporting libraries as well.
Binary-level hacking of Ubuntu-supplied libsoxr.so.0 to replace libgomp.so.1 with libiomp5.so.
- Possible, but an insanely low-level and hack-ish. Not appropriate for public-release software.