Removed problematic INSTALL_NAME_DIR

[Bo98]

The INSTALL_NAME_DIR interfered with CMake's install process. With it in place, linkage looked like this:

$ otool -L /usr/local/lib/liboctomap.1.9.0.dylib 
/usr/local/lib/liboctomap.1.9.0.dylib:
	@rpath/liboctomap.1.9.dylib (compatibility version 1.9.0, current version 1.9.0)
	/Users/bo/Downloads/octomap-1.9.0/octomap/lib/liboctomath.1.9.dylib (compatibility version 1.9.0, current version 1.9.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)

This clearly doesn't look right - it has references the build directory rather than the install directory.

Upon removing INSTALL_NAME_DIR, we get the much better looking:

$ otool -L /usr/local/lib/liboctomap.1.9.0.dylib 
/usr/local/lib/liboctomap.1.9.0.dylib:
	@rpath/liboctomap.1.9.dylib (compatibility version 1.9.0, current version 1.9.0)
	@rpath/liboctomath.1.9.dylib (compatibility version 1.9.0, current version 1.9.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0)

For the avoidance of doubt, here's what @rpath is:

$ otool -l /usr/local/lib/liboctomap.1.9.0.dylib
[-snip-]
Load command 15
          cmd LC_RPATH
      cmdsize 72
         path /usr/local/lib (offset 12)

I do note the comment saying that INSTALL_NAME_DIR "seems to be necessary". Looking back, I couldn't find a precise reason why but it was added 8 years ago. CMake at that point had very poor install support on macOS - it didn't even know what an @rpath was. Now it has very good support and you rarely need to worry about it.

[ahornung]

Yeah, it was added 8 years ago in this commit (contributed by a user): 5d5ef79

I never had a chance to actually test under MacOS, so if it works now better without it then I'm sure we can remove it.