Add support for CCO's to Gatesets.

[tanujkhattar]

Is your feature request related to a use case or problem? Please describe.
Gatesets currently accept any cirq.Gate instance or sub-type as a valid input parameter. For special operations, like GlobalPhaseOperation, CircuitOperation etc, they have flags like unroll_circuit_op or accept_global_phase_op to control the behavior.

ClassicallyControlledOperation was recently introduced as a new type of operation that wraps traditional gate operations but don't have an op.gate property. As a result, there's currently no way to specify in a gateset definition that a CCO should be accepted or not.

Describe the solution you'd like
Support for CCOs should be added to gatesets, either by adding an additional flag or by adding a .gate property to the CCO operation, which can simply return the .gate of it's underlying sub_operation.

What is the urgency from your perspective for this issue? Is it blocking important work?
P1 - I need this no later than the next release (end of quarter)

[daxfohl]

xref #4683

Also we generally support op.gate.on(q) is at least the same behavior as the original op, at least when gate exists. Tags are the only thing I can think of that doesn't carry over. So this would be a departure.

If we want to make CCO.gate return some CCGate class, this generally requires subcircuit-gates to be implemented too. #4725 (comment)

[vtomole]

This should be supported after we've agreed on a design.

[tanujkhattar]

@95-martin-orion To confirm, this is post 1.0 IMO. Please confirm.

[95-martin-orion]

@95-martin-orion To confirm, this is post 1.0 IMO. Please confirm.

Confirmed. This requires design, and CCOs remain functional without it in the meantime.