smite-ir: add Reconnect operation

[NishantBansal2003]

Add an IR Operation::Reconnect that closes the transport, re-runs the Noise handshake, and re-exchanges init with the originally negotiated features. NoiseConnection gains reconnect, backed by a new Connector that retains the dial parameters.

On reconnect the executor discards every negotiation and channel that had not received funding_signed, matching what the target retains across a BOLT 2 reconnection.

Replace PendingChannel::funding_built: bool with funded_channel_id: Option<ChannelId>, which drives the pruning and the existing temporary_channel_id-reuse checks.

[NishantBansal2003]

With Reconnect, there is one problem that might reduce fuzzing efficiency. If there is a Reconnect between SendOpenChannel and RecvAcceptChannel, or between SendFundingCreated and RecvFundingSigned, the buffer is cleared. So, we will not receive those messages even if the target has already sent them, and the target will not resend them if it has not sent them yet. In either case, we currently wait for 1s, then time out and stop the execution.

This could hurt fuzzing efficiency somewhat. Some possible solutions I can think of are:

1. Do not allow Reconnect between these affine-consuming operations. This means reordering the mutator, builder, and generator so they cannot build such programs. However, this would prevent us from fuzzing these cases and might also prevent us from finding bugs that occur specifically because of such a Reconnect.
2. Infer whether the message is expected from the existing negotiation or channel state. We already have negotiation or channel state that can tell us whether an accept_channel or funding_signed is expected. If it is expected, we receive it. Otherwise, we make the operation a no-op. The drawback is that we cannot produce a compound Recv variable for its fields to be reused later in the execution. This also somewhat goes against our current affine type model. If we gate Recv operations like we do for RecvChannelReady, we do not really need the affine type at all.
3. Reduce the receive timeout for these operations. This would reduce the impact on fuzzing efficiency, since we already use a similar model for cases where the target might ignore one of our messages. See smite-scenarios: reduce read timeout to 1s #136.