[cmake] Fix rpath issues with shared libraries in non-system installation paths

When installing ERT into non-system installation prefixes, binaries will not
be linked correctly as the rpath is wrong. On my system this looks like this
(notice the not found!):

ldd /home/mblatt/src/dune/3rdParty/ert/lib/x86_64-linux-gnu/libecl.so.1.0
	linux-vdso.so.1 =>  (0x00007fff7fbff000)
	libert_geometry.so.1.0 => not found
	libert_util.so.1.0 => not found
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f45dd80d000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f45dd5f6000)
	liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007f45dca25000)
	libopenblas.so.0 => /usr/lib/libopenblas.so.0 (0x00007f45db57a000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f45db2f8000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f45db0f4000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f45dad69000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f45ddca1000)
	libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007f45daa53000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f45da83d000)
	libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f45da607000)

The same holds for binaries where ert is linked to.

This can circumvented by setting LD_LIBRARY_PATH, but this seems rather cumbersome. Instead in this patch we follow the approach suggested in http://www.cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH