Pulse support in coherence routines

[aeddins-ibm]

What is the expected behavior?

There are some convenient functions in Ignis for measuring T1, T2, T2*, called t1_circuits, etc. It's particularly handy that t2star_circuits provides the nosc kwarg.

Currently, the wait times between pulses are implemented by concatenating a large number of identity gates. This gets the job done, but is limited in 1) the user needs to provide the length of a single identity gate (which can be hard to find), 2) it's a little annoying to have to generate circuits first which I then have to convert via schedule if I want to add custom pulses, 3) minor point but AFAICT working with id_gates limits time resolution to steps of 160dt vs working with steps of 16dt in Pulse, and 4) aesthetically it's a hack since qasm nominally doesn't have the notion of time.

Would be nice to have analogous Pulse-based functions, t1_schedules, t2_schedules, t2star_schedules. One possible approach:

• Remove the 'id_gate_time' argument. Replace it with backend argument, from which dt and relevant pulse definitions will be extracted. (Maybe more granular inputs than backend would be better?)
• Remove the number_of_gates argument. Replace it with delay_times_approx argument, which will take the corresponding (list of) desired delay times in seconds. Internally the function should immediately round these to the nearest multiple of 16dt (or whatever is the correct requirement), and build the schedules using these rounded times. These rounded delay_times should be returned to the user. (Could still just be xdata as in the original functions, though maybe delay_times is more descriptive?)
• Build the expected Pulse schedules and return to the user.

Some questions:

• Does the above make sense?
• For Pulse, do we need to replace the argument qubits with the argument physical_qubits, in order to identify the correct pulse definitions, etc?
• If the above all sounds good, would it make sense to deprecate the qasm-based t1_circuits, etc?