Bug 1692631 - Fix the profiler marker for IPC message reception on Windows. r=gerald

This point in the code is the end of receiving a message, not the start
(note the `if (partial) { break; }` above), so it should be marked
accordingly.  The profiler frontend is expecting the end marker;
currently two of the four reported time intervals are `unknown` on
Windows, and this patch fixes that.

(Recording the receiving start time is complicated, because we don't
have a `Messsage` object until we've read the buffer with the (end of
the) header, and it might make more sense to timestamp it before the
first receive operation.  Currently, neither channel implementation
attempts this.)

Differential Revision: https://phabricator.services.mozilla.com/D105094

ipc/chromium/src/chrome/common/ipc_channel_win.cc

@@ -435,7 +435,7 @@ bool Channel::ChannelImpl::ProcessIncomingMessages(
       // has no routing ID), but we only emit a profiler marker for messages
       // with a routing ID, so there's no conflict here.
       AddIPCProfilerMarker(m, other_pid_, MessageDirection::eReceiving,
-                           MessagePhase::TransferStart);
+                           MessagePhase::TransferEnd);
 
 #ifdef IPC_MESSAGE_DEBUG_EXTRA
       DLOG(INFO) << "received message on channel @" << this << " with type "