CompilationTargetGateset support in GridDeviceMetadata

[verult]

Part of #5050

Adds a new property to represent a set of CompilationTargetGatesets, to provide users a convenient way to transform their invalid circuits to a valid one supported by the device, and to allow for a device to potentially include gates from different viable CompilationTargetGatesets (e.g. SYC and SQRT_ISWAP).

Other alternative approaches:

• Always provide only one CompilationTargetGateset. In cases where multiple CompilationTargetGatesets are valid, the code selects only one of them to surface.
  • How to determine which target gateset to surface?
  • The current solution of allowing a set of CompilationTargetGatesets is simple to implement and gives users a choice (because of different error characteristics for example)
• Add a utility function in cirq_google but outside the device implementation and GridDeviceMetadata, to avoid increasing the API surface of GridDeviceMetadata. IMO considering CompilationTargetGatesets as a piece of device metadata makes sense as every device could (and should in most cases) have a group of target gatesets. Keeping this in GridDeviceMetadata makes the compilation feature more discoverable.

The JSON diff came out gnarly due to indentations. Basically I added a new GridDeviceMetadata object that contains compilation_target_gatesets.

Part of device refactor (#5050)

cc @dstrain115 @maffoo @MichaelBroughton @mpharrigan @tanujkhattar @wcourtney

[tanujkhattar]

@MichaelBroughton @verult One high level comment: Should this property exist on DeviceMetadata instead of GridDeviceMetadata ? It can return None / empty tuple by default, signifying that device doesn't yet have a compilation target. For most vendor devices, we anyway need to migrate their transformers to the new framework and hence create compilation target gatesets for them so it would make sense to integrate those compilation targets with their devices. Thoughts ?

[tanujkhattar]

Looks good overall. Blocking to discuss the comment above on whether we should add this directly to DeviceMetadata.

[tanujkhattar]

I take my previous comment back -- I agree we should add the compilation target gateset property to grid device metadata because DeviceMetadata doesn't even have a gateset property on it.

We can merge once the nits are resolved.

[tanujkhattar]

LGTM after adding original json deserialization test to make sure deserialization without compilation target gatesets property works as expected.

[tanujkhattar]

Don't change existing json test. Add a new test instead so that the existing json deserialization works as expected.

[verult]

We have to at least set compilation_target_gatesets to [], otherwise the test will fail saying the JSON serialization of the instance from the repr file does not match the JSON file. So IIUC we can't deserialization backward compatibility anyway. I could perhaps add an _inward file instead and keep the old entry there.

[tanujkhattar]

Ah I see, my bad. Let's add an _inward file instead.

[verult]

Added a json_inward which is a copy of the old json, and the corresponding repr_inward.

[CirqBot]

Automerge cancelled: There are merge conflicts.

[CirqBot]

Automerge cancelled: A required status check is not present.

Missing statuses: ['Pytest Windows (3.7)', 'Pytest Windows (3.8)', 'Pytest Windows (3.9)']