Issue Description:

On Darwin, the swift compiler takes care to place its own rpath (the location of the swift standard library) after any user-specified rpaths.

On Linux this is not the case

To reproduce, start from a new executable package (swift package init --type executable) (called test), and build with

swift build -Xlinker -rpath -Xlinker /usr/local/lib

On macOS this produces a binary with a runtime library search path containing 2 entries, as follows:

• /usr/local/lib (the user-provided search path)

• the location of the swift standard library

To observe this use otool -l as follows:

$ swift build -Xlinker -rpath -Xlinker /usr/local/lib
Linking ./.build/x86_64-apple-macosx10.10/debug/test
$ otool -l ./.build/debug/test
...
Load command 18
          cmd LC_RPATH
      cmdsize 32
         path /usr/local/lib (offset 12)
Load command 19
          cmd LC_RPATH
      cmdsize 112
         path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx (offset 12)
...

On Linux this same command produces a binary whose runtime library search path has 3 entries, as follows:

• the location of the swift standard library

• /usr/local/lib (the user-provided search path)

• $ORIGIN, a symbol indicating the directory containing the binary (similar to Darwin's @executable_path).

This can be observed with the readelf command:

$ readelf -d ./.build/debug/test
...
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/lib/swift/linux:/usr/local/lib:$ORIGIN]

It seems strange that the Linux version gives a different order than the Darwin one, I would expect the order to be consistent across platforms. Furthermore, I think the Darwin order is the correct one as it allows each layer to override a lower one (a swiftPM user can override swiftPM's authors which in turn can override swiftc). It's possible that on Darwin, SwiftPM should also insert @executable_path between user-specified search paths and compiler-specified ones.