Ensure that disk-allocations get cleaned up upon rollback

In the case we:
    1) create transaction
    2) call $process->create_disk_allocation
    3) rollback transaction
We need to be assured that the disk allocation is deleted.  Since disk
allocations are created in separate processes, there is no log in our
transaction about the disk allocation creation, so we have to log it
ourselves.
Avoid using the ghost_class if possible

My hand tests show that this has the same behavior of ensuring that the
disk allocation is cleaned up when the current transaction commits but
not if it gets rolled back.
set status with 'update_status' not 'status'

The way UR automatically creates undo-subroutines inside of transactions
makes it so that when the transaction rolls back an invalid status
transition will occur.  If the status method has logic to disallow such
transitions it will not allow us to roll back UR transactions, which is
bad.
Add 'genome process view' command
Have create_disk_allocation create the log_directory
Processes can now be run

The branch that bsub's and runs the workflow on LSF (with flow) has been
pretty extensively hand-tested.  It wasn't clear how to automate that
testing until we have a test-database service that we can use.
bugfix: call execute instead of non-existing method
Doc related touchups
Only set env variables if they aren't already set.
Reduce duplication between Viewers
Use %ENV instead of 'env' on cmd line
Use JSON library in a simpler way.
Make bsub'd workflows go to the workflow queue.
Eliminate spurious sprintf
Use 'error_message' instead of 'status_message'
Use Sys->read_file instead of File::Slurp
Merge pull request #214 from davidlmorton/process_run

Genome::Processes can run and be viewed