Fix WaitForLock() and config.Set() lock

[mdrohmann]

https://www.pivotaltracker.com/story/show/177913373

[MDrakos]

Looks good to me just some minor cleanup

[mdrohmann]

Okay, this works now, I had to re-iterate because:

• there was another bug in the pidlock implementation that only happened on Windows:
  When a process successfully locks the lockfile, but the file contents have a PID that is still running, TryLock returned false, but the file was locked (and never released).
• Next problem: I realized that I wanted to just do file locking without the PID check. I remember that when I initially wrote the pidlock.go code, I added the PID check in order to ensure that we can recognize lock files that try to lock processes that are not running anymore. But that is already handled by flock or LockProcessEx. So, it is unnecessary, and unnecessary complexity leads to errors as we have seen, BUT:
  • in process.NewActivation we use the PID functionality of the pidlock.go implementation (but not the actually locking). That leads to follow-up story: https://www.pivotaltracker.com/story/show/178223007
  • the PID check actually did something: it ensured some INNER process synchronization. If TryLock was run in the same process, the flock.TryLock call always succeeds (that's only on Linux and Mac), because it allows several locks by the same process(!). But as soon as the first TryLock call writes its PID in there, the second one notices that there is already a running PID. => So, when we remove the PID check, our locking process needs a different kind of inner-process mutex to synchronize for these cases.

The suggested solution implemented in this PR is as follows:

1. As the external package gofrs/flock already ensures inner process synchronization, I used that for the config synchronization
2. I fixed the pidlock implementation as much as I could
3. I filed a story to get rid of the pidlock implementation: https://www.pivotaltracker.com/story/show/178223007
4. Because gofrs/flock provides shared and exclusive file locking, I changed the lock for Reload() to a shared lock ie., it can be run in parallel by several processes. It was easy and should speed things up, especially as we know have several processes contending for resources.