split options
reflect option split in show_help
create link to makeflow on install
use makeflow_exe instead of argv[0]
split makeflow main based on mode of operation
fix broken tests
trifurcation.

Inspired by today's cctools meeting.
split documentation
include nick's change
preparing for clean merge
Merge temporary fixes for a clean merge
return 0 from main
Separate tools into their own .c, create makeflow_common.[ch]
ignore new executables
do not remove makeflow_analyze in test cleanup
Merge branch 'makeflow_bifurcation' of git://github.com/rampantmonkey/cctools into rampantmonkey-makeflow_bifurcation

Split makeflow into three executables:

makeflow         - To run workflows
makeflow_viz     - To create visual representations of workflows
makeflow_analyze - To generate statistics from dag's static analysis

Currently the split is quite ugly, and the code  is expected to have quite a
few changes before it can be officially released. I am merging to master now so
that Casey, Patrick, and I (Ben) can synchronize on makeflow changes.

Per Casey:

Makeflow has two typical usage patterns: Run my workflow and Tell me something
about my workflow.

Both patterns require parsing the workflow description and building the dag but
have different user expectations. Running the dag is a potentially long,
unresponsive process so it is important to output informative messages during
run time. On the other hand, interrogating the dag is a short process which the
user expects the results to follow a specific format (DAX, Dot, PPM, ...).

These two behaviors are at odds (as evidenced in #257).

The most robust solution is to move the short, interrogative behaviors into a
separate program. A separate program clearly shows the user the purpose of each
tool. This also frees up many letters for command line switches (an extremely
   	 limited resource) and removes the need for parsing hacks
(rampantmonkey:makeflow_display_filename).