stack exec doesn't set LD_LIBRARY_PATH after building a foreign library

### General summary/comments (optional)
Cabal's new `foreign-library` support allows building haskell code into objects that can be called from C programs. In a typical usage of this feature, one builds shared libraries that are then called from an existing binary, which may already be installed in the system. In order to support this, the relevant `lib/` directory in stack's working directory should be added to `LD_LIBRARY_PATH`, so that the existing executable can find our freshly built object.

At the moment, stack doesn't seem to do this.

cabal-install does have this feature, see haskell/cabal#4064.

### Steps to reproduce

1. build/install a project with a `foreign-library` object
2. ` $ stack exec env | grep LD_LIBRARY_PATH `
3. observe that `LD_LIBRARY_PATH` (or its macos equivalent `DYLD_LIBRARY_PATH`) is unset or unchanged

### Expected

Ideally, stack would add the `lib/` directory inside `.stack-work/` to any existing entries in `(DY)LD_LIBRARRY_PATH`. E.g.:
```
$ stack exec env | grep LD_LIBRARY_PATH
LD_LIBRARY_PATH=/tmp/test/.stack-work/install/x86_64-linux-nopie/lts-10.3/8.2.2/lib/
```

### Actual
The library search path is left unchanged and programs are unable to find the freshly built and locally installed shared library. As a workaround, the environment variable can be set manually, but this is tedious, and the path that should be used changes depending on the stack configuration used (because the stackage version, as well as the system architecture, become part of the path that needs to be set).

### Stack version
1.6.3

### Method of installation
Arch Linux package manager