fix: FENCE blocks qubits, not frames

[kalzoo]

Closes #143

This takes a simple approach, reusing the PreviousNodes mechanism already employed for frame dependencies:

• FENCE instructions "use" a qubit, in that they hold exclusive use of that qubit while "executing"
• All RF Control instructions (anything operating on a frame) "blocks" a qubit, in that they must wait for previous "users" to complete but they do not exclude one another. They do this for all qubits named within their frame. This allows, for example, a NONBLOCKING PULSE 0 "'ro_tx" to play concurrently with NONBLOCKING CAPTURE 0 "ro_rx" as is commonly done.

This does add a couple redundant edges on the timing graph, such as between subsequent FENCE and FENCE 1, but I think that price is worth paying for the simplicity of the approach. It's not incorrect, it's just overkill.

I initially added a new variant, ExecutionDependency::Qubit, but considered that the effect of a Qubit dependency is itself in nature nothing more than a StableOrdering, and so it was not worth the breaking change to distinguish between the two. So, this change as written is just a bugfix and not a breaking change.

Note the effect of this change in the timing graph (this is the non-overlapping fences snapshot test in graphviz_dot.rs):

Prior to this change, the FENCEs would have serialized these instructions, because of the presence of a 0 1 "cz" frame in the program (not shown). Each FENCE would have "used" that frame and thus they would have been seen as blocking one another, in turn serializing the PULSEs that they wrap.