Fix RPC call to use correct bit count for data transmission

[bssth]

In LegacyNetwork::broadcastRPC, the payload length is calculated via bs.GetNumberOfUnreadBits(). That function returns "how much is left to read," not "how much was written."

This is wrong for broadcastRPC. Before the packet goes out, open.mp fires the registered onSendRPC handlers (Pawn.RakNet, anti-cheat plugins, etc.). Any handler that reads the payload - which is a perfectly normal thing to do - moves the read pointer forward. After the handler chain, GetNumberOfUnreadBits() no longer equals the full packet length. Worst case: Pawn.RakNet deliberately sets the read pointer to 8 bits past the ID byte, so for a one-byte payload it returns zero, and the client gets an RPC with an empty body.

That's exactly how it surfaced for me in Core::setWeather: the SetPlayerWeather packet (one-byte WeatherID) was arriving at the client empty, and every connected player got kicked with the "SA-MP 0.3.7 Exception" dialog on any /setweather call. The same bug silently mangles SendClientMessage/GameText broadcasts too - the string gets truncated from the start or the end depending on what the handler happened to read.

Every other method in the file (sendPacket, broadcastPacket, sendRPC) already uses GetNumberOfBitsUsed(), which returns the amount of data actually written and doesn't care about the read pointer. broadcastRPC was the odd one out.

On a vanilla server with no read handlers the readOffset stays zero, so both functions return identical results. That's why the bug sat unnoticed for years. The correct fix is straightforward: the send path shouldn't depend on what a handler did with the read pointer at all.