Header Modularization

Goals/Objectives/Needs/Wants

1. Single include path (-I...). Without a single include path, builds, IDE's, and other tools become unmanageable.
2. Easy checkout, commit, merge, switch, and other source control operations.
3. Works well regardless of build engine; remember that users don't all use bjam or CMake.
4. Doesn't break users existing scripts, IDE setups, etc. OK to break developers and release managers scripts.
5. Easy library subset creation.
6. Minimizes developer mistakes like failure to merge, commit, all files that changed.
7. All maintenance occurs withing the library's libs/... directory. (Subset of (6), but important enough to list separately.)
8. Easy scripting (inspect, unmerged changes, release mgt, etc.) ((7) goes a long way to achieve this.)
9. Works well with installers.
10. Supports test-on-demand and test-library-against-other-branch.