GCS_MAVLink: schedule current waypoint rather than immediate send

[peterbarker]

This message may not fit in our outgoing buffer

[peterbarker]

Tested by graphing MISSION_CURRENT.seq while doing a wp set

[WickedShell]

This looks like a serious regression actually. This was intentionally acting as our ACK. The problem with queuing it like this is that by the time we send it it may not be current. Heck when we sent it here we may have already moved on 3 items later. But it is important to be able to get an ack that when you target a DO_LAND_START for example to know that it actually jumped to the item. Without an ack of some form it's impossible to validate that you jumped to any DO item, which means a GCS has to trust the user to manage error detection. Without this change you at least could detect that we did definetly react to it. Packet loss & buffers means it may have happened without an ack, but if you got an ack it definetly happened.

If we can't send here we should queue, but we need some form of ack here.

[peterbarker]

This looks like a serious regression actually. This was intentionally acting as our ACK. The problem with queuing it like this is

#16714