These extended profiles match the way that you can configure a
thermocycler in protocol designer. They support a mix of cycles (more
than one per profile) and out-of-cycle steps, while keeping structure
down to hardware. That last part is sadly important to support
currently-exposed details up from the hardware controller.

This is a thermocycler command that accepts a structured sequence of
temperatures and wait times instead of a flat list.

A profile is a list of either steps or cycles; cycles are a repetition
count plus a list of steps.

The actual _functionality_ of the command is exactly the same as
thermocycler/runProfile; the only change is pushing down the structure
of the information, which is currently lost when creating a runProfile
command and thus unavailable to protocol clients for display.

This PR does a couple things with thermocycler command text.

First, it changes the phrasing of the thermocycler/runProfile command
text to make it more clear that no cycles are involved: it's just a big
list of steps.

Second, it adds a command text for the new
thermocycler/runExtendedProfile command, which does have the structured
data necessary to render things as cycles. This unfortunately makes it a
multilevel list, thus worsening the annoying problems with it.

Closes RQA-2771

Use the new thermocycler/runExtendedProfile to implement
ThermocyclerContext.execute_profile() at or above protocol api version
2.21.

This new version of the command preserves the structure of the thermal
cycles and will allow the desktop app and ODD to present appropriate
information to the user.

Co-authored-by: Ed Cormany <[email protected]>

This handles non-normalized durations (i.e., all seconds) now. I think
it is janky.