Atomicity overhaul

[shumpohl]

Currently the atomicity is half-baked into the type system. A pulse template is atomic if it is always translated into a single waveform. It currently is possible to translate all templates to waveforms by passing them in the to_single_waveform argument of create_program. However they do not implement the interface of AtomicPulseTemplate i.e. have a build_waveform method.

Some "transforming" pulse templates are not subclasses of AtomicPulseTemplate but are expected to behave as such if their wrapped pulse template is atomic:

• MappingPulseTemplate
• ArithmeticPulseTemplate

This might lead to problems if they are used in AtomicPulseTemplates that expect their subtemplates to be atomic like AtomicMultiChannelPulseTemplate and ArithmeticAtomicPulseTemplate. One example for this is here: #577 (comment)

This requires some design thought. Maybe something like a TransformingPulseTemplate or TransparentPulseTemplate?

[shumpohl]

I think atomicity should not be part of the type system if possible. It should be possible to treat all pulse templates as atomics. Side remark: The advantage of the previously used property is_interruptable was that it denotes if a pulse template can be translated into multiple waveforms. See #134

Proposal:

• Add build_waveform abstract method to PulseTemplate
• Add ComposedPulseTemplate class that has a default build_waveform implementation which is based on create_program and to_single_waveform
• Relax subtemplate requirements for all classes to PulseTemplate

@peendebak Would that make AtomicSequencePulseTempalte obsolete?

[shumpohl]

Intermediate solution is to use _is_atomic

[shumpohl]

New solution:

1. Add to_single_waveform: Optional[Literal['always'|'never']] as a PulseTemplate.__init__ keyword argument and use that in _create_program.
2. Create a default build_waveform im for PulseTemplate based on a SingleWaveformBuilder