Fix ENet Buffer data/length ordering issue

[raymcveety]

Our team discovered this issue when we were trying to send a UDP broadcast packet using enet_socket_send().

On Linux, the broadcast works as expected, but on Windows the function returns -1.
Calling WSAGetLastError() returns a code of WSAEFAULT indicating an error with the pointer parameters.

This lead us to inspect the parameters accepted by enet.socket_send and how they were subsequently transformed/translated into the parameters for WSASendTo where we noticed the ENetBuffer passed in "buffers" as LPWSABUF

Here's essentially what we were passing to socket_send for the buffer:

b := enet.Buffer {
    data = raw_data(bytes),
    dataLength = len(bytes)
}

bytes_sent := enet.socket_send(network.broadcast_sender, &addr, &b, 1)
// below we report error 

Currently enet.Buffer is defined in win32.odin with the order (data first):

Buffer :: struct {
	data:       rawptr,
	dataLength: uint,
}

But LPWSABUF (which is a long pointer to WSABUF) expects the opposite ordering of the data and length (length first):

typedef struct _WSABUF {
  ULONG len;
  CHAR  *buf;
} WSABUF, *LPWSABUF;

So the crash was due to the length being interpreted as the data/data being interpreted as length.

The fix is simple (and we verified locally it eliminates the WSAEFAULT) which is to reverse the order of the members of the Buffer struct in win32.odin

Buffer :: struct {
	dataLength: uint,
	data:       rawptr,
}

We verified the forked compiler builds with these changes, our project builds on the forked compiler, and the WSAEFAULT no longer occurs when we call enet.socket_send using the enet.Buffer struct.

[raymcveety]

This is ultimately passed in as LPWSABUF which is expected to be length first