"malformed mach-o: load commands size" with a multi-package cabal.project

We have a project with over 50 packages we run into infamous OSX linker problem.

In `otool -l` dump of some dylib there are

```
Load command 21
cmd LC_LOAD_DYLIB
cmdsize 80
name @rpath/libHSdpndnt-mp-0.2.4.0-b3458e24-ghc8.2.2.dylib (offset 24)
time stamp 2 Thu Jan 1 02:00:02 1970
current version 0.0.0
```

for each dependency, which is fine.

## Local libraries names aren't mungled

```
Load command 45
cmd LC_LOAD_DYLIB
cmdsize 72
name @rpath/libHSenv-config-0-inplace-ghc8.2.2.dylib (offset 24)
time stamp 2 Thu Jan 1 02:00:02 1970
current version 0.0.0
compatibility version 0.0.0
```

local package names aren't mungled: we have "long" names `futurice-this` and `futurice-that`, `servant-algebraic-graphs` ...

## Each local library's dylib is in own dir

While there is one `LC_RPATH` for store:

```
Load command 330
cmd LC_RPATH
cmdsize 56
path /Users/toku/.cabal/store/ghc-8.2.2/lib (offset 12)
```

There are one per local dependency:

```
Load command 320
cmd LC_RPATH
cmdsize 96
path /Users/toku/hmr/dist-newstyle/build/x86_64-osx/ghc-8.2.2/log-cloudwatch-0/build (offset 12)
Load command 321
cmd LC_RPATH
cmdsize 88
path /Users/toku/hmr/dist-newstyle/build/x86_64-osx/ghc-8.2.2/periocron-0/build (offset 12)
...
```

I'd say that fixing the second part, having single libdir in `dist-newstyle` (on OSX?) would save this problem too. For now it prevents splitting big "industrial size" repository into smaller packages (we want to have separate packages, as it's easier to manage).

We *could* use internal libraries to workaround this, but the problem would still persist for cases like https://github.com/phadej/acme-kmett (I didn't tried to compile it on OSX).

[otool-hyperloglog.txt](https://github.com/haskell/cabal/files/1824209/otool-hyperloglog.txt)

The above dump is for `hyperloglog` `.dylib` from acme-kmett, it has 111 commands, small-dep app in our repo has 332, biggest (which overflows 32k limit) has 420.

cc @christiaanb