Enumerate weirdnesses in the protocol

For beginners, there are quite a few weird surprises. We should make a list, for reference.

Here's the ones I can think of right now:
## Enums differ in size for no good reason

```
1. BeamFrequency:
PlayerShip object:
beam_frequency: enum
ClientPacket::SetBeamFreq:
beam_frequency: enum

2. MainScreenView:
PlayerShip object:
main_screen_view: enum
ClientPacket::SetMainScreen:
main_screen_view: enum
```
## Enums are sometimes used in "nullable" form (offset by 1)

For example, in `GameMasterMessage` the `console_type` field can be 0, which means _no console_. If it's greater than 0, subtract 1 from the value to get the normal ConsoleType enum value
## Some packets are (at least originally) intended for sendings integers, but contain non-integers

For example, the client packet `ConvertTorpedo` has major type `valueFourInts`, but really only contains one f32. .. _sigh_
## Bools are always either 1 bytes or 4.. unless they're 2

PlayerShip.shields_up is a 2-byte bool, and it seems to be the only one in the entire protocol
## Strings often contain junk data

It's very common for strings read from the network to contain random junk bytes after the \u0000 (UTF-16 NULL) character.
## WeaponsConsole object updates can contain junk data

The official server sometimes sends WeaponsConsole updates that contain fields in the bit mask that are sent on the wire, but (seemingly) contain just junk. The reader has to check the tube_status fields, to know which tube data can be trusted.
## All arrays are either fixed-size or terminated by an integer.. except when they aren't

The server packet GameOverReasons contain an array of strings. This packet seems to end at the end of the packet frame, instead of being terminated by an integer. This is the only known known instance of this behaviour.
## All strings are utf16-le.. except the welcome message

Every string in the protocol is encoded as utf16-le (no bytemark), except for the string in the server packet Welcome. That one is ASCII.. because.. reasons
## All non-ObjectUpdate packets always contain all fields... except IncomingAudio

For some reason, IncomingAudio seems to be the only packet there the number of valid fields depend on the contents of the packet. If this was the first field, this could be a case of a missed subtype field, but it's the second field... _double sigh_

The issue body is the only entry point mentioned and already lists the protocol inconsistencies to document. Review each example against the protocol specification, organize the findings into a beginner reference, and consider the work done when the listed exceptions are recorded accurately and clearly.

Written by the indexing model from the issue text.