virtio-msg: fix-up response matching as discussed Oct 23

Simplify the response matching as discussed in the PR and in the Oct 23
meeting.

* Bus messages have a dev_num and it is normally 0 so we don't need to
  say that matching dev_num if only for transport messages.
* Drop msg_id from matching.  Altough the msg_id would normally match
  there may be some cases where it would not.  The token field should
  be unique for a given dev_num.
* This simplifys the description of the matching tuple as well

Signed-off-by: Bill Mills <bill.mills@linaro.org>

Author: wmamills

transport-msg.tex

@@ -363,22 +363,18 @@ \subsubsection{Message Correlation}
 The token field in the message header is part of a tuple that is unique during
 a request to response interval.
 \begin{itemize}
-  \item Bus Message tuple: ( 1, 0, \field{token} ).
-  \item Transport Message tuple: ( 0, \field{dev_num}, \field{token} ).
+  \item Message tuple: ( \field{dev_num}, \field{token} ).
 \end{itemize}
 
 Rules:
 \begin{itemize}
   \item The request originator assigns a non-zero \field{token} for every
     request such that the tuple is unique for all inflight requests.
   \item Event (one-way) messages \textbf{MUST} set \field{token}=0
-  \item A response \textbf{MUST} echo \field{token}, \field{dev_num} (for
-    transport), and \field{msg_id}.
+  \item A response \textbf{MUST} echo \field{token} and \field{dev_num}.
   \item Reception of unknown or already completed correlation tuples
     \textbf{SHOULD} result in discarding the response without further protocol
     action.
-  \item Implementations \textbf{MAY} deliver responses out of order unless a
-    specific message definition mandates ordering.
 \end{itemize}
 
 \subsection{Bus Operation}