Autotools RFC: Round 2

Changes since Round 1:
- Rebased on current master
- Moved configure to root srcdir, and added a Makefile there
- Split into several Makefile.am's with recursive build [1]
- Work towards building correctly under gitian
- Fixed/verified several build scenarios
- Fixed up 'make dist' to work as a viable end-result packaging mechanism [2]

1. Personally I believe that splitting up the build is a major regression from RFC1. This was done by request here. Most projects end up spending lots of time moving in the opposite direction, as a recursive build tends to be slower, more complicated, and more-error prone. That proves to be the case here as well, but I've attempted to handle it as gracefully as possible.

2. 'make dist' can be used to produce a bootstrapped tarball with git information included, intended for distribution as an 'official source release'. This is the equivalent of taking a fresh git clone, running './autogen.sh', and tar'ing up the result. This is the common procedure for autotools projects.

At this point I consider it to be merge-ready, with the exception of verification of gitian descriptors and documentation. Presumably removal of the old makefile.* would coincide with updated documentation.

Several things can be improved and cleaned up after merge (dealing with versioning, for example), but I've tried to ignore these things as much as possible for the sake of a quick merge.
--

Here is the second go at an Autotools build system replacement. It is meant to be a drop-in replacement for the current system(s), providing the same features with no net changes. It can also live side-by-side with the old system while sharing the same build-related variables in order to facilitate a smooth transition.

I hope the benefits are obvious enough: A single/shared build procedure, portability, ease of packaging, ease for downstreams, ease for repository maintainers, cross-compilation, etc. I don't vouch for Autotools in any way, in fact, this configure.am is downright ugly (mainly just because of mingw though), but it's portable and well-established.

I've opted not to write the documentation yet, because I would like to see what comments/concerns come out of the first round of review before committing to anything.

This does away with the need for qmake, as the Makefile is capable of generating everything it needs in a portable way.

Qt-creator can be used with the Autotools plugin, and is working nicely. For those who wish to use it this way, install the Autotools plugin from the 'about' menu, then open Makefile.am as a project. It handles the build procedure, so there is no need to mess with the command-line procedures listed below.

Building from CLI:
For Linux, assuming the dependencies have been met, the build procedure looks like this:
```
./autogen.sh
./configure
make
```
Same for OS X, but the pkg-config path needs to be hooked up from macports first:
```
echo "/opt/local/share/aclocal" | sudo tee -a /usr/share/aclocal/dirlist
```
For mingw it's the same, but you will need to provide lots of paths in the form of:
```
./autogen.sh
CPPFLAGS="-I/path/to/include -I/path/to/other/include" LDFLAGS="-L/path/to/libs -L/path/to/other/libs" ./configure
make
```
In addition, there are helpers for qt and boost to help with finding some locations.
Use ./configure --help to see the available options.

Native windows built is untested, as I don't have a windows environment at my disposal.

Gitian should be working for win32 builds. I've guessed at Linux but have not yet verified.

'make check' will run the unit tests and print the results.

I've done my best to avoid adding any new behavior or features, and I would much prefer to aim for feature-parity before making any improvements.

TODO:

- Verify gitian descriptors.
- Add documentation