S-bit packet ordering

[jsturdy]

There are two sources of mismatch between the OTMB and OH.

1st question: How do we group the 8 clusters into a packet?

OTMB is using:
packet0 = cluster3 & cluster2 & cluster1 & cluster0
packet1 = cluster7 & cluster6 & cluster5 & cluster4

OH is using:
packet0 = cluster0 & cluster1 & cluster2 & cluster3
packet1 = cluster4 & cluster5 & cluster6 & cluster7

I'm somewhat partial to the OTMB method because cluster0 is in bit0, which seems nice, but either one is fine as long as we agree. Could even do:

packet0 = cluster0 & cluster2 & cluster4 & cluster6
packet1 = cluster1 & cluster3 & cluster5 & cluster7

The 2nd question: what order do we transmit the packets's frames (each packet is split into 4 separate frames).

The OTMB is using:

frame0 = packet[7:0] & FRAME_SEP;
frame1 = packet[23:15];
frame1 = packet[39:24];
frame2 = packet[55:40];

The OH is using:
frame0 = packet[55:48] & FRAME_SEP;
frame1 = packet[47:32];
frame1 = packet[31:16];
frame2 = packet[15:0];

I'm again somewhat partial to the OTMB method because bit0 is in frame 0, which seems nice, but again I don't think it really matters as long as we agree on something.
It should be easy to change on either end.

[jsturdy]

Proposal: change src/link/link_tx_trigger.vhd
to correlate with:

else if(CEW3) begin
            RCV_DATA        <= {w0_reg[15:8], w1_reg, w2_reg, gem_rx_data}; // OH format
          //RCV_DATA        <= {gem_rx_data,w2_reg,w1_reg,w0_reg[15:8]};   // tmb/emulator board format
            k_char[7:0]     <= w0_reg[7:0]; 
            LTNCY_TRIG      <=  lt_trg_reg;
            NONZERO_WORD[3] <= |gem_rx_data;
            mon_in[3]       <= (!gem_rx_lossofsync[1]) && (gem_rx_notintable[1:0]==2'b00) && (gem_rx_isk==2'b00); // no k-bits set
        end