Add configurable timeouts for sync:start.

[tekante]

Fixes #53

This sourced out of some troubleshooting with Mauricio where it took his machine quite a while to do the initial sync.

It occurs to me that maybe we should also allow for specification of this by environment variable since if someone needs this they probably need it the whole time. Especially since the sync:start will likely be getting trigged via an up alias in .outrigger.yml

[grayside]

Agreed about an environment variable.

Do we really have situations where both timeouts will be independently adjusted? Should we just have a --timeout flag and set the container start timeout to a percentage of the total timeout?

[tekante]

Sans a desire to detect an issue as soon as possible the answer is likely no. I've actually not seen anyone suffer from waiting for the container to start timing out, it was added as a function of "since I'm in here . . . "

[febbraro]

Can we just set it via the outrigger.yml file?

[grayside]

The need is for specific convoluted operations, projects with large codebases, and laptops with performance issues. Config file covers one of these

[febbraro]

@grayside What do you mean "Config file covers one of these"

[grayside]

Hit send too fast I suppose:

1. Convoluted operations, such as moving the docroot aside and building a new one.
2. Projects with large codebases, such that a build can pull in many, many files
3. Laptops/hardware with performance issues, such that the need to support Unison might cause problems.

Of these, a config file driven approach to setting the timeout is really only routinely applicable to point 2. Point 1 is exception and would be better to set in the moment (perhaps even with an ignore-timeout sort of option), and point 3 is idiosyncratic to the individual, pointing to a need for a shell setting or an .outrigger.local.yml if it's to be set in a file.