Metadata Files and Associated Verbs

### Overview


***See documentation for the changes pending here: http://jbohren-ct.readthedocs.org/en/metadata-file/index.html***

This PR (wip) covers a multitude of usability improvements to catkin_tools. This is in part motivated by features which used to be supported by `rosbuild` such as context-aware building and partial cleaning of the workspace.

The key architectural feature of this patch is the creation of a metadata directory called `.catkin_tools` in the root of a catkin workspace. This directory is not only used by the verbs to determine the location of the root of the workspace, but also it is used to store persistent information between builds. The API for interacting with this information is presented below.

The information stored in the `.catkin_tools` directory is contained in independent "configuration profiles" between which a user can switch without having to create multiple workspaces or do his or her own bookkeeping of command-line arguments.

Another focus of this patch is the organization and clarification of the command-line interface to catkin_tools verbs. This involves the addition of argument groups and the re-organization of arguments between verbs. For example, several of the "workspace configuration" arguments like the specification of source, build, and devel spaces have been moved from `catkin build` to `catkin config`. This simplifies the parameters to `catkin build` and makes it easier for newer users to figure out the important command-line options.

This patch also adds several new verbs which take advantage of this metadata utility.

### Example Workflow

This PR currently enables an initialization and build workflow like so (try it yourself):

```sh
$ mkdir -p ~/my_ws/src
$ cd ~/my_ws
$ catkin config # declare this a catkin workspace with a default configuration
$ ls -a
.  ..  .catkin_tools src
$ cd src
$ git clone https://github.com/ros/catkin.git
$ git clone https://github.com/ros/rospack.git
$ git clone https://github.com/ros/cmake_modules
$ git clone https://github.com/ros/ros.git
$ pwd
~/my_ws/src
$ catkin build # call `build` from anywhere in the workspace 
<building everything...>
$ catkin clean --build --devel # clean products without dangerous `rm -rf`
$ cd rospack
$ catkin build --this # context-aware building based on working directory
<building rospack and its dependencies...>
```

Some cool context-aware aliases that this PR curently enables:

```yaml
these: build --this              # Build this package and its dependencies
this: build --this --no-deps     # Build only this package
those: build --start-with --this # Build this package and all those which depend on it
```

### Related Issues

Once complete, this PR should address the needs of the following issues:
-  (#27) *build: Add marker file to workspace root*
  - Adds the marker file.
-  (#67) *new verb proposal: catkin info*
  - Creates the verb which dumps the marker file info along with other information.
-  (#10) *build: allow execution from anywhere under the root of the workspace*
  - Uses the marker file to find the root of the workspace, and then build from there.
- (#68) *build: Add "--clear-cmake-cache" argument`
  - Adds a `clean` verb.
- (#11) *build: prevent mixing catkin_make and catkin build on same build folder`
  - Reports an error if someone tries calling `catkin build` with a buildspace created by `catkin_make`
- (#2) *move common functionality out of catkin_build and into a neutral module*
  - Moves most of the common functionality into the `catkin_tools` module

### IRC Discussions

- [#ros 2014-07-21](https://botbot.me/freenode/ros/2014-07-21/?msg=18362909&page=1)
- [#ros 2014-07-29](https://botbot.me/freenode/ros/2014-07-29/?msg=18818922&page=1)

### TODO(NE)

- [x] PEP8 silliness (use https://pypi.python.org/pypi/autopep8/)
- [x] document all new features in RST documentation
- [x] enable building from anywhere in the source tree
- [x] add `init` verb to mark a directory as a catkin_tools workspace
- [x] add `clean` verb which deletes `buid/`, `devel/` and re-initializes `.catkin_tools.yml`
- [x] add `--cmake-cache-only` argument to `catkin clean`
- [x] add `info` verb to dump workspace information
- [x] make workspace arguments in new verbs non-positional
- [x] place metadata in individual profile directories, with a `config.yml` file under `catkin_tools` which lists the default profile
- [x] create `profile` or `configure` verb or something similar for managing profiles
- [x] ~~separate "configuration-like" arguments out of `build` verb~~
- [x] add `configure` verb to set build configuration without actually building
- [x] enable context-aware building of a package (only that package, starting with that package, or that package and deps)
- [x] add `--this` argument to `build` to build the package defined by the currently-enclosing directory
- [x] clean up refactor of `Context` class (includes separating out verb-independent functionality of `common.py`, `color.py` and `run_unix.py`)
- [x] ~~require `config`/`init` call to use `catkin build` with stored configuration~~
- [x] automatically generate `.catkin_build` marker if `build` `config` or `init` are called
- [x] ~~don't store cmake/make args (for now)~~
- [x] store cmake/make args via `catkin config`
- [x] unify context configuration
- [x] make build (config) options only apply tmporarily
- [x] replace all user-facing description of "metadata" as "profiles"
- [x] sort profiles alphabetically in `catkin -h`
- [x] remove `catkin info` verb (duplicate behavior with `catkin config`) this will be resurrected later in time
- [x] ~~remove `catkin init` verb (duplicate behavior with `catkin config`) -- replace with alias to `config --init`~~ leave in `catkin init`
- [x] ~~have `catkin config --init` create directories like source space~~ don't add directory-creating functionalities, maybe at some point later add a`catkin mkspaces` for making the source space dir
- [x] add checks to detect incompatible build configs like merged vs unmerged spaces, or install vs noinstall
- [x] add checks to detect if the user has used catkin_make or catkin_make_isolated previously in a workspace
- [x] verify that `--workspace` and  `--profile` arguments work with all verbs
- [x] make `catkin clean` display help if run with no arguments
- [x] fix `--start-with --this` so that you can run `catkin build --this --start-with foo_pkg`
- [x] document python API functions & classes
- [x] create a consistent appearance (colors/formatting/spacing) for all verbs
  - [x] build appearance
  - [x] config appearane
  - [x] clean appearance
  - [x] profile appearance
  - [x] init appearance
- [x] add helpful output to `catkin init` (like `initialized empty catkin workspace in...`) and then `To build your workspace blah blah...`) 
- [x] simplify `CMAKE_PREFIX_PATH` persistence in context

### Other Ideas

- add a `catkin build --from-paths DIR` argument for building all packages in a directory
- store a list of the last set of packages which were built. if they've changed or their paths have changed since the last run, prompt the user to re-source the setup file in the develspace (or just always put this line at the end of build)

### Configuration Profile (Metadata) Details

- Metadata is stored in a `.catkin_tools` directory 
- This directory contains the following:
 - A simple instructive README file explaining what the directory is
 - A `profiles.yml` file describing the active profile (if different from `default`)
 - One or more directories containing configuration values, where each directory corresponds to a "configuration profile"
- Each configuration profile directory contains individual yaml files for verb-sepcific metadata. I.e. `catkin build` creates/updates the file `.catkin_tools/<PROFILE-NAME>/build.yml`
- When initializing the metadata directory (either automatically when calling a verb which writes to it, or explicitly using `catkin init`), the metadata module checks to see if that directory is contained within another catkin_tools-based workspace.

See https://github.com/jbohren-forks/catkin_tools/blob/metadata-file/catkin_tools/metadata.py for metadata API documentation.
You probably mean `target dependency management`? Like between genmsg generation targets and targets which build code which use the generated code?