feat: Synchronous Disk State Check

[PatKoperwas]

Some negatives with the current approach (evented FS watcher)

1. Build loops are possible
   If you forget to ignore something, its possible to get stuck in a
   build loop, where the command outputs a file, which triggers a
   rebuild, which outputs a file, which triggers...

2. CPU usage
   Evented watchers aren't free. Larger the project, the more %CPU it
   takes to just watch the FS

3. Wasted work
   After everysave, a build is triggered - which isn't ideal as in most
   cases one will save more than 1 file before tabbing over to the
   browser. This leads to more wasted CPU spent rerunning commands on
   every save.

New approach: Check FS on HTTP request.

Flipped the sequence. Previously:
-> FS Change
-> Pause Proxy
-> Rebuild
-> Unpause Proxy

New sequence:

-> Request comes in
-> Pause Proxy
-> Check for FS changes
-> If changes exist, rebuild
-> Unpause Proxy

This has several advantages:

1. 0% CPU usage while idle
2. No wasted builds

The obvious downside is that now each request needs to check the FS for
changes.

However, with these changes it is possible to chain multiple tychus's
together. When using that feature, a --wait flag has been added. Using
that flag will tell tychus to block until the user specified command
finishes. This command will most often be some script or quick series of
commands and not something blocking like a webserver.

[PatKoperwas]

Resolves #3