Split out Boost.Python

Splits out Boost.Python into a separate formula, à la #30845, so that most of boost can be bottled even when Boost.Python is desired. Supports python2 and python3 simultaneously. Tested with clang against brewed and system Python 2 and brewed Python 3 on 10.9. Building boost-python takes 11 minutes on a single-core VM on my mid-'09 MBP; building boost took more than three hours.

The acceptance process for this should probably look like:

* [x] split out Boost.Python
* [x] get input from Homebrew and homebrew-science maintainers (you are here!)
* [x] rewrite Homebrew formulas (ledger, libpst, libtorrent-rasterbar, mapnik, pyexiv2) and homebrew-science formulas (galsim, graph-tool, openimageio, pykep, vigra) to depends_on boost-python instead of boost --with-python, and test
* [ ] alert the mailing list and synchronize commits to master, since this may affect other taps, unless this is too melodramatic

This formula doesn't attempt to install Boost.MPI's Python bindings, which depend on Boost.Python. Nothing in homebrew or -science seems to depend on MPI's Python bindings and there's not an obvious reason to use them for new development. They were already not correctly installed (i.e. "import boost.mpi" didn't work) even when building boost --with-python and --with-mpi. (If this becomes important, a boost-mpi package with a --with-python option might be the cleanest way to make sure Boost.MPI and its bindings are built in a compatible way.)

Is adding a "--with-python" option back to boost that dies with a message telling users to install boost-python instead helpful?
There's a corner case for which this doesn't work; vigra in homebrew-science can need boost-python and wants it in c++11 mode if vigra is being built.with("c++11"). If boost and boost-python are both already installed without c++11, we can require boost with c++11 and boost will be rebuilt but nothing will detect that boost-python doesn't have c++11 so boost-python won't be rebuilt. This leaves the boost libraries in an inconsistent state wrt c++11 and maybe means the vigra bindings will either fail to build or segfault.

Do you think this is important enough to drop back to having a separate :cxx11 option and dying if incompatible options are requested, @mistydemeo?

I could also add a c++11 option to boost-python and:
- depend_on boost => "c++11" if build.with?("c++11")
- build in C++11 mode if build.with?("c++11")  **or** Tab.for_name("boost").with?("c++11")

which at least tries to do the right thing but in a slightly magical way that can't be switched off.