Support repeated measurement keys in cirq.Result

[maffoo]

Part of #4274

[maffoo]

I've rebased this on master including the separation of cirq.Result into an ABC. One design question here is what the new interface for accessing 3D arrays of repeated measurements should look like. I've called in measurements2 as a placeholder. Any thoughts @95-martin-orion?

[95-martin-orion]

One design question here is what the new interface for accessing 3D arrays of repeated measurements should look like.

Let's cover this at our meeting Thursday - there are a bunch of open threads here and I'd like to get them woven together before rushing ahead on this.

[95-martin-orion]

A pretty self-explanatory implementation of Result as described in the RFC, though there's a comment from @Strilanc there you should take a look at before we commit to this.

[95-martin-orion]

Two things:

• This also needs to check that the dimensions for each qudit are the same - e.g. (3, 2) != (2, 3).
• This feels like the wrong place for this check to live, since presumably every sampler/simulator is going to require it. Could we move it up to the Sampler superclass?

[maffoo]

Moved this into a helper function Sampler._get_measurement_shapes in the base class. Note that this is basically a preliminary version of the "measurement_key_shape" protocol proposed in #4888.

[95-martin-orion]

@maffoo Heads up: due #4899 requiring access to Result.records and needing to be submitted before the v0.14 in a couple weeks, we need to merge this PR as soon as possible.

[95-martin-orion]

Approved, but requires conflict resolution before merging. The change looks fairly minor.

[daxfohl]

I noticed one surprising (to me anyway) behavior of ResultDict is that, when passing in records but not measurements, and any measurement occurs more than once, then ResultDict.measurements['key'] fails even if key was only measured once.