Support nested procfile

[pinealan]

Implements the following to allow a Procfile to include other Procfiles to

• Recursively parse -f <path> entries in a Procfile
• Add abstraction between a procfile entry and a process entry
• Starts processes from nested Procfiles in the corresponding Procfile's directory using tmux -c [working-directory] flag

An example setup in a repo with 1 top-level Procfile and 2 nested Procfiles

# Procfile
-f backend/Procfile
-f frontend/Frocpile
tests: yarn test:watch

# backend/Procfile
api: python -m server.http
db: mysql start

# frontend/Procfile
web: yarn start
assets: gulp watch

To distinguish between processes started from different Procfiles, the relative directory path will be appended to each proc

system          | Tmux socket name: overmind-123456
system          | Tmux session ID: om
system          | Listening at ./overmind.sock
backend:api     | Started with pid 52489...
backend:db      | Started with pid 52490...
frontend:web    | Started with pid 52491...
frontend:assets | Started with pid 52492...
tests           | Started with pid 52499...

A few undetermined behaviors with other existing flags that I'd like to hear the maintainer's opinions on:

• Procfile contains nested entries AND procfile is not ./Procfile
• Procfile contains nested entries AND root is not directory containing top Procfile

[DarthSim]

Hey @pinealan! Thanks for your work, it's a pretty interesting idea. Though I cant merge it as is for the following reasons: 1) This PR breaks --root flag. Actually, the whole idea of the --root flag is not compatible with nested Procfiles as I see it. I can't say if --root flag is somehow popular, but I can't remove it. 2) I don't like the idea of extending Procfile. Procfile is a universal format used by many systems and tools. If we add something Overmind-specific to this format, a Procfile become incompatible with the other tools. Thus it worth implementing a new format rather than extending the existing one.

[pinealan]

you raised the exact same points as my team's senior engineer who introduced me to overmind :)

I see the concerns but I've already been rolling this for my own projects and like it a lot, so I guess I'll have to keep my own fork