RFC: Overhaul for dependencies, pull-tester, Gitian

This is a major rewrite of our build and release process. There are still some rough edges, but it’s working enough to begin discussing. For now, please keep the discussion high-level rather than focusing on small details (paths, naming, syntax, etc). It will need to be broken up into chunks, likely with the pull-tester and dependencies builder going in first, then Gitian once that's settled.

Warning: Incoming wall of text.

The meat of it is the new dependencies builder. See the README in the depends folder for more detailed info. It unifies many of our build procedures so that they may be re-used for similar purposes. The major points are:

- Pull-tester and Gitian build processes have been unified.
- Pull-tester can test all possible configs on all supported OS’s.
- All dependencies are now built with unified recipes. No more hackish per-target shell scripts. This also means that release binaries will share the exact same dependency versions, rather than a random assortment as they are now.
- Gitian builds are now painless and require no intervention since the results are chained together.
- Dependencies are no longer a local issue for the the pull-tester. Everything can be handled in git alone. Anyone can deploy their own pull-tester if desired.
- Devs may elect to use these dependencies rather than installing them via their OS. This is especially helpful on OSX as it avoids the need for homebrew/macports.

For now, only building from Linux x64 is supported, but last time I tried it worked fine from OSX with the exception of building Qt (fixing that is on my todo list). Building should work from anywhere, it just hasn’t been a priority to actively work outside of Linux x64 yet, so the paths aren’t tested.

Build-side tools may either be installed locally or built as native dependencies. For example, the linux/win builds use locally installed gcc/mingw, but the OSX build builds and installs its own clang-based toolchain. Ideally all local build-side dependencies would be removed, but that can come down the road if it proves necessary.

The dependencies builder creates a cached payload for each package that it builds. Each is automatically rebuilt as needed, either when the build recipe or its dependencies are changed. Old payloads are automatically cleaned. The result is a set of files that are automatically glued together into a prefix suitable for building Bitcoin. This process is entirely automated and deterministic, suitable for running before each  Bitcoin build. If nothing has changed, it completes in less than a second.

A POC pull-tester has been setup to use them: https://travis-ci.org/coryfields/bitcoin/builds . It caches these packages and re-uses them as necessary (note that caching is not currently happening due to some Travis account restrictions, I’m actively working with the Travis guys on this. Once this is in place builds will only take a few min). The end-result is that Bitcoin is always built with a known set of dependencies, which are entirely controlled by us. No files from the build-machine are ever used. This means that the pull-tester can be OS/distro/architecture agnostic, so we don’t end up in a situation (as we are currently) where the pull-tester is a static environment that can’t be touched.

Note that the pull-tester does not currently run any tests, it only checks for build failure. Tests will be added once caching is in place, otherwise builds would take far too long.

Gitian has been made to use these dependencies as well. Now, Gitian releases are built with the exact same procedure as the pull-tester, making dogfooding much easier. As mentioned for the pull-tester above, this lifts the OS restriction on Gitian, so we’re free to move to more recent distros/releases. Builds have been verified as deterministic locally, but I haven’t yet compared with non-local builds. Also worth mentioning, because we build all dependencies ourselves in a sandbox, a single base image can be used for all builds.

For now, a Gitian patch is needed to make use of the dependencies cache. I’m sure this could be improved, it’s just my first stab at something that works. See the PR here: https://github.com/devrandom/gitian-builder/pull/62

With this patch, the sources are fetched by the dependencies builder, and cached for re-use. Existing files in the inputs folder will not be used, so the first build will take a good big longer.

The build results for this PR, as built by the changes in this PR (gitception?) can be seen here: https://travis-ci.org/theuni/bitcoin/builds/30927912 . Currently linux32/linux64/win32/win64/osx64 are tested.

TODO:
- General cleanup
- Get the caching feature into Gitian, in some form
- Clean up the Gitian build results. For now, they just copy the binaries out haphazardly.
- Verify Gitian determinism
- Document the dependencies generator
- Get the caching working for Travis
- Once caching is working, add tests.
- Update build/release notes
Any reason for not just keeping all hashes (recipe hashes, build ids, ...) full sha256 checksums (without any cut), and only at the last step, for the filename, shorten things if necessary?