Refactor NewSourceManager() to give more control over lockfile interaction

[sdboyer]

#853 introduced more sophisticated handling of the sm.lock lockfile created by NewSourceManager() to guarantee only one process is working on the cache directory at a time. This is a nice addition, as it should solve the easy cases where a lock file gets left around when a dep process quits in a way that prevents cleanup (e.g. a panic). That's a fairly rare case right now, but still - a benefit.

However, #853 also changes the logic so that, rather than erroring out immediately if the lockfile exists (and refers to a valid process), it blocks. This is primarily a crude mechanism of allowing e.g. a CI server to run multiple jobs simultaneously - even though they can't actually proceed in parallel, they at least won't quit if there's another process working in the cache; they'll just wait for
the other process to end, then proceed. (This crude mechanism could conceivably create livelocks in systems relying too heavily on it, but that's a different problem).

The main issue I want to deal with here is expanding the API to give the caller of NewSourceManager() more granular control over this process. I don't know exactly what the API should look like, but we can't just change this call such that it can block for arbitrarily long, without providing more control mechanisms to the caller.

If we can avoid it, I would probably prefer that we NOT use context.Context for this specific purpose. NewSourceManager() also needs to take a context, but that's more about allowing termination of the *sourceMgr once it's created and running - not controlling these initial setup semantics. Apart from that, though, I'm pretty open to ideas; we don't have to worry about preserving the existing signatures.

[sdboyer]

cc @matjam

[sdboyer]

seems like this actually isn't the route we necessarily want to go. can reopen later if we change our minds.