fix(read): guard against unbounded buffer allocation on peer-declared frame length

[AdamMagued]

Fixes #223

Problem

ws.ReadFrame and wsutil.ReadMessage previously allocated buffer memory sized directly by the peer-declared frame length (make([]byte, int(f.Header.Length))). Because Reader.MaxFrameSize defaulted to 0 (unlimited), an untrusted peer could declare a massive payload length (such as 16 GiB with a 64-bit length header) and trigger a Go runtime memory exhaustion panic, terminating the process.

Solution

• Added ws.DefaultMaxFrameSize set to 16 MiB (16 * 1024 * 1024 bytes) to cap frame allocations on unconfigured readers.
• Added ws.ReadFrameWithLimit and updated ws.ReadFrame to reject frame lengths exceeding the limit with ws.ErrFrameTooLarge before allocating memory.
• Added wsutil.DefaultMaxFrameSize and wired default limit checking into wsutil.ReadMessage, wsutil.readData, and wsutil.NewReader.
• Aliased wsutil.ErrFrameTooLarge to ws.ErrFrameTooLarge for cross-package error identity.
• Added unit tests in read_test.go and wsutil/helper_test.go verifying that frames declaring oversized lengths return ErrFrameTooLarge without allocating buffer memory.