Add return type to (*RelayMsgs).Send()

[mark-rushakoff]

This adds a new return type indicating the accumulation of errors
encountered during message sending and the count of successful batches
sent. The return value is not yet used anywhere and existing behavior is
preserved so far.

There are two questionable existing behaviors:

1. On the first part of the batching, RelayMsgs.Success is &&-ed with
   the newly received success, and when sending the "leftover" messages,
   the Success field is overwritten to the final value. This means we
   could report success if all early batches failed but only the last
   batch to the destination chain succeeded.

   I intend to address this in a following change by adding an
   equivalent Success() method to the SendMsgsResult type which properly
   reports if all sent batches succeeded.

   I am not sure how this will differ from existing behavior in the
   wild. I assume we will see more failures than before.

2. It is unclear to me, when there are multiple batches to be sent, and
   one batch fails, is it safe to send a following batch, or should the
   entire send operation abort? I don't yet have a thorough
   understanding of what will be sent here to judge for myself which is
   more appropriate.

/cc @jackzampolin and @jtieri for those behavior questions.

[jtieri]

Definitely some good questions.

1. After reading through this it's a bit unclear to me as well. It looks like we treat full batches as successful only if all preceding full batches were successful but partial batches can be considered successful regardless of if preceding full batches were successful. I'm not very sure why this would be desirable behavior.
   To further add to the confusion, it looks like when we consume the Succeeded variable at the call sites of Send() we just assume every pending packet was successful if we get a true value for Succeeded.

relayer/relayer/naive-strategy.go

Lines 430 to 437 in 5a54ea6

	if msgs.Send(ctx, log, AsRelayMsgSender(src), AsRelayMsgSender(dst)); msgs.Success() {
	if len(msgs.Dst) > 1 {
	dst.logPacketsRelayed(src, len(msgs.Dst)-1, srcChannel)
	}
	if len(msgs.Src) > 1 {
	src.logPacketsRelayed(dst, len(msgs.Src)-1, srcChannel)
	}
	}

2. I believe if the channel is UNORDERED then we can safely send another batch of msgs even if a previous one failed, since there is no guarantee on what order the packets in the queue will be successfully processed. If the channel is ORDERED the packets must be successfully processed in FIFO order, so essentially if a batch failed we would need to retry or query the packet commitments again and ensure that packet n was processed before packet n+1

I'd like to see @jackzampolin's thoughts on these bits as well.

[mark-rushakoff]

I'm going to merge this PR now since it doesn't change any existing behavior, but still +1 to hear from @jackzampolin on the questions.