There were at least two code paths which might acquire `.RLock()`
recursively:

1. `Setup*()` -> `createResult()`
2. `Setup*()` -> `Networks()`.

On its own, it's not a problem, but if `.Load()` is called concurrently,
it might do `.Lock()` in between recursive `.RLock()`s, which would lead
to a deadlock.

See #125

Fix by introducing a contract on the way mutex is acquired.

Add a test facility to verify for such mistakes via build tags:

* `go test -race` or `go test -tags deadlocks` activates deadlock
  detection

Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>

fix: recursive RLock() mutex acquision