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
* [ ] get input from Homebrew and homebrew-science maintainers (you are here!)
* [ ] 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?
I'm not sure what the use case for the universal build is and I don't see that anything actually uses it; `for i in *rb; do grep -q boost $i && grep -q with-python $i && grep -q universal $i && echo $i; done` doesn't return any hits. Should we maintain it?