RFC: change `dynlib` handling on linux to use standard dynamic linking instead of runtime loading via `dlopen`
In the current scheme, when using `dynlib` on linux, Nim will generate code that loads the library via `dlopen` and successive `dlsym` calls. This is problematic for several reasons:

* linking on linux should typically be done using the `soname` - linking via filename appears to work on developer system but will cause issues when binary is used on a machine where the named file is symlinked to a different version: see also http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html - note that typically, when passing a library name to C compiler via `-lXXX`, the compiler will translate the `XXX` (linker convenience name) to the `soname` as part of the linking process - in nim, one has to be extra careful because wrapping libraries without using header files may lead to subtle ABI mismatches.

* opening library via `dlopen` means a larger binary that takes longer to load - the generated code is verbose and slow compared to what `ld` can do using the special linking sections in the executable

* linking via `dlopen` means tools like `ldd`, `gdb` and others show incomplete information about application dependencies, making dependency analysis harder than it has to be

* using plain `libXXX.so` file (without versioning information, as given by soname) requires the plain `.so` to be installed both when running and when compiling the program - this plain file is a symlink that's only installed by `-devel` packages that users typically don't keep installed - this makes it harder to both distribute and compile nim programs. it also promotes situations where things work on developer computers but not on end-user systems, leading to unnecessary friction in the release process.

Instead, I'd like to suggest that Nim uses standard linux linking when using `dynlib` - that will solve all of the above problems: fewer ABI issues, faster startup/load times, smaller binaries, standard tools work and no devel packages are needed.
