Devices: Separate concerns in devices

[balopat]

Problem: The device interface in Cirq defines constraints on the hardware (validation) and decomposition of gates. Many actual device instantiations also support duration_of from when Cirq had schedules. These provide three separate functionalities, validation, mutation, and information. Durations are particularly problematic because it is not true that there is a map from a set of gates to a duration in the hardware, sometimes compilation will behave differently across a single gate type. These should be separated out. Devices can be containers that contain these separate concerns, but it should be possible for users to swap in and out different versions of these functionalities (we should prefer delegation to subclassing, instead of an interface that does each three, there should be three different interfaces each of which can be specified).

Rough requirements

• Define interfaces for separate concerns, validation, compiling to native gate sets, and information

[daxfohl]

@balopat @MichaelBroughton This seems like a fairly straightforward refactor, just creating the interfaces, moving the implementations into their own classes, and wrapping that in a Device facade. Probably with known devices as subclasses of Device with __init__(): super().__init__(MyValidator(), MyDecomposer(), MyConstraints()). Are there any big additional things needed here or any reason you see this as not being fairly straightforward?