Support pressure advance changes without waiting for movement to stop

[dc42]

Some slicers now adjust pressure advance between moves in an attempt to improve print quality. This doesn't work well with RRF because the movement queue is emptied when changing PA. See https://forum.duet3d.com/topic/37604/3-6-0-beta-4-issues-with-frequent-m572-due-to-adaptive-pa.

[dc42]

Some implementation options:

• Store the PA values for all extruders in each move object. We support up to 8 extruders on Duet 3 Mini and up to 20 on Duet 3 6HC/6XD. Even if we use 16-bit floats to store the values, This implies that each movement object will increase in size by 16 bytes on Duet 3 Mini and 40 bytes on 6HC/6XD.
• Could we get away with configuring PA values per tool instead of per extruder, i.e. all extruders used by a tool use the same PA value? If so then we only need t store one PA value in each movement record.
• We could use a separate queue to record changes to PA and relate it to the number of completed moves. Each record in this queue could store the PA change of a single extruder, so the record could be quite small. However, if the slicer changes PA between every pair of moves then the number of PA change records needed would be similar to the number of movement records needed. This solution is substantially more complex than the previous two.
• Perhaps we could use the existing queue system for delaying commands to sync them with motion? An issue is that we need to sync the change in PA to the point at which the move is committed, which is a little ahead of when it is actually executed. So we would need the motion system to peek into the queue prior to committing the move, so that it knows how much PA to apply.

To support dynamic PA on CAN-connected extruders, I think the only realistic option is to include the PA value(s) in the movement message. We would need to reduce the maximum number of drivers supported on an expansion board from the current value of 8. Supporting several different values of PA would require more space in the CAN message, which is another reason why restricting PA configuration to a single value per tool would be desirable.