Atomicity overhaul

[terrorfisch]

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: https://github.com/qutech/qupulse/pull/577#issuecomment-826136949

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

[terrorfisch]

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?

[terrorfisch]

Intermediate solution is to use _is_atomic