New RPATH logic (ready for review)

Done TODOs:
- [x] `patchelf` uses `RUNPATH` by default. We need to use `--force-rpath`.
Done. 

- [x] Non-determinism
Added more robust handling of this in: https://github.com/conda/conda-build/commit/2b948578e8c4afff999c30a523001e1c790335af
TL;DR is that it definitely looks like a kernel race bug; RPATH is being set correctly, we're just re-reading it a little too fast sometimes (maybe once every 5-6 builds for one .so).

- [x] `patchelf --force-rpath` clears the `RUNPATH` is this an issue?
This is the desired behavior.

- [x] `patchelf` reads the RUNPATH and reports it as the RPATH. We should use `readelf` to more reliably read the information, so that we can see exactly which is set.

I just checked the patchelf.cc source.  It'll print `RPATH` when there's no `RUNPATH`, and we clear the `RUNPATH` above via `--force-rpath`, so this is fine, no need to use `readelf`:

```C++
    /* Walk through the dynamic section, look for the RPATH/RUNPATH
       entry.

       According to the ld.so docs, DT_RPATH is obsolete, we should
       use DT_RUNPATH.  DT_RUNPATH has two advantages: it can be
       overriden by LD_LIBRARY_PATH, and it's scoped (the DT_RUNPATH
       for an executable or library doesn't affect the search path for
       libraries used by it).  DT_RPATH is ignored if DT_RUNPATH is
       present.  The binutils `ld' still generates only DT_RPATH,
       unless you use its `--enable-new-dtag' option, in which case it
       generates a DT_RPATH and DT_RUNPATH pointing at the same
       string. */
    static vector<string> neededLibs;
    dyn = (Elf_Dyn *) (contents + rdi(shdrDynamic.sh_offset));
    Elf_Dyn * dynRPath = 0, * dynRunPath = 0;
    char * rpath = 0;
    for ( ; rdi(dyn->d_tag) != DT_NULL; dyn++) {
        if (rdi(dyn->d_tag) == DT_RPATH) {
            dynRPath = dyn;
            /* Only use DT_RPATH if there is no DT_RUNPATH. */
            if (!dynRunPath)
                rpath = strTab + rdi(dyn->d_un.d_val);
        }
        else if (rdi(dyn->d_tag) == DT_RUNPATH) {
            dynRunPath = dyn;
            rpath = strTab + rdi(dyn->d_un.d_val);
        }
        else if (rdi(dyn->d_tag) == DT_NEEDED)
            neededLibs.push_back(string(strTab + rdi(dyn->d_un.d_val)));
    }
```

- [x] Only change the RPATH for new files. 
That's the default behavior -- the only time this differs is when `post_link_patch_rpath` flag is set in `.condarc`, which required use of the conda `rpath` branch.  However, that was a temporary stop-gap measure.

- [x] What should be the right thing with RPATH vs RUNPATH?
We should forcibly set RPATH every time via `patchelf --force-rpath --set-rpath`.  This will clear the RUNPATH if present and always set an RPATH.  Even when the RPATH is empty.

- [x] Fix code to do the right thing with RPATH vs RUNPATH
The logic above has been implemented.

Outstanding:
- [ ] Why is it necessary to delete existing RPATHs?
It's not so much that we're deleting existing RPATHs, it's more that the new logic figures out exactly what the RPATH needs to be and always sets it.  When no libraries are being dynamically linked to, the RPATH is essentially set to nothing.  The fact that this results in an existing RPATH being cleared is really just an artifact of existing libraries having an unnecessary RPATH set. 

- [ ] Difficult to understand error messages
These will be addressed by the `link.py` support, which prints much better error messages in the face of link issues.

- [ ] We need to decide what the default behavior will be when we detect link errors.  Should we treat them as fatal, preventing the build from completing unless an explicit flag is provided (`--ignore-link-errors`), or as warnings, only failing when an opposing flag is provided (`--fail-on-link-errors`)?

I have gone back and forth a few times.  I think the former is the best option.  The error message should reference a wiki page or docs URL where more information about the "link error" issue can be provided, whilst also saying that conda build can be re-run with an `--ignore-link-errors` flag to allow the build to continue.

i.e. something like this:

```
Error: external linkage detected to packages with no known conda equivalents:
    /usr/lib64/libSM.so.6
   /lib64/libgmodule-2.0.so.0
   /usr/lib64/libpangocairo-1.0.so.0
   /usr/lib64/libjpeg.so.62
   /usr/lib64/libICE.so.6
   /usr/lib64/libpango-1.0.so.0
   /usr/lib64/libpangoft2-1.0.so.0
   /lib64/libgobject-2.0.so.0
   /usr/lib64/libgomp.so.1
   /lib64/libglib-2.0.so.0
See conda.pydata.org/docs/link-error.html for more info.
Tip: run `conda build --ignore-link-errors` to ignore these errors and build the package anyway.
The resulting package will not be installable on other systems unless they also have the
dependent libraries listed above installed.
```

- [ ] Document new functionality.
- [ ] Blog post describing new functionality (referencing docs above).
- [ ] Remoe all instances of `pdb`

<!---
@huboard:{"order":669.5,"custom_state":""}
-->

These need to be moved inside the Config object.