Race conditions make restrict_mut failures possible.

Our current code in tor-circmgr assumes that all failures of restrict_mut are programming errors: if the spec object didn't return a.supports(b)==true, then why would we call a.restrict_mut(b)?

But it turns out that this can happen in a few ways, due to time-of-check vs time-of-use delays. There are several cases where we check supports in one task, use that to decide to send a circuit to another task, and that second task calls restrict_mut. Between those two calls, other requests for that circuit may have restricted it in a way incompatible with what it originally supported.

Found while working on #421 (closed) and #329 (closed).