GridDeviceMetadata: allow qubit pairs in both directions

[verult]

Fixes #5169

@MichaelBroughton do you think this API makes sense?

[MichaelBroughton]

This looks good. We are already sorting QIDs here as per @dstrain115 's comment in the issue (so things like serialization are not order dependent). Since this change is happening in the subtype and not the parent type (DeviceMetadata), how would we feel about just adding the (r, l) pairs in the tuple to go along with the exsiting (l, r) pairs in sorted order ? We wouldn't have to introduce a new type and it would keep things a little simpler.

[verult]

Discussed offline. Will instead use a FrozenSet[Frozenset[cirq.Qid]] to represent a collection of qubit pairs, similar to the deprecated SymmetricalQidPair but keeping it simple by using a frozenset.

The option of keeping both (l, r) and (r,l) in the set has the downside that len(qubit_pairs) is 2x the actual size.

[verult]

Pushed the latest changes. I opted to keep the qubit_pairs in the constructor as a Frozenset[Tuple[Qid, Qid]] to enforce the requirement that the pair must have exactly 2 elements, and since ordering doesn't matter in the constructor, using the pair as a frozenset isn't necessary.

My preference is to reuse the SymmetricalQidPairs which is being deprecated and removed in #5290, which:

• Requires that the pair has exactly 2 elements, unlike a bare frozenset
• Better describes the intention of the data structure for the pair.
  In this case we could use SymmetricalQidPairs in the constructor as well.

[MichaelBroughton]

LGTM

[CirqBot]

Automerge cancelled: Pull Request is not mergeable.