[OvOhao]

Changes

LogSetOutputFunction gave SDL the address of a Go struct (logOutputFunctionCtx) as userdata. That caused two problems:

• Nothing on the Go side kept the struct alive after the call. SDL keeps the pointer and passes it back for every log message, so the struct could be collected while SDL still used it (Possible use-after-free: LogSetOutputFunction hands SDL a Go pointer that nothing on the Go side keeps alive #624).
• When the callback is a capturing closure or a method value, or data holds a Go pointer, the struct contains Go pointers. The default cgocheck then panics at the call with argument of cgo function has Go pointer to unpinned Go pointer (Possible cgo pointer rule violation: LogSetOutputFunction panics for closures and non-constant data under the default cgocheck #626).

SDL has only one log output function at a time. So this change stores the callback and data in the existing logOutputFunctionCache / logOutputDataCache variables, guarded by a sync.RWMutex, and passes NULL as userdata. logOutputFunction reads the current values through LogGetOutputFunction. The unused logOutputFunctionCtx type is removed. log.c and the public API do not change.

The caches are set before SDL_LogSetOutputFunction is called, so the first message after registration already sees the new function. The lock is released before the user callback runs, so a callback can call LogSetOutputFunction or LogGetOutputFunction itself.

Testing

In Docker (golang:1.27, Debian libsdl2-dev 2.32.4):

• go build ./sdl succeeds before and after. go vet ./sdl reports nothing in log.go. The existing vet findings in other files are unchanged.
• go test -run 'TestLog' -v ./sdl: TestLog and TestLogSetOutputFunction pass before and after. The same tests also pass with -race after the change.
• I also ran a temporary test (not included in this PR). It registers a closure that captures a variable and passes &struct{...} as data, runs runtime.GC() a few times, and then calls Log. Before: panic: runtime error: argument of cgo function has Go pointer to unpinned Go pointer at the LogSetOutputFunction call. After: the callback runs and receives the data.

Fixes #624
Fixes #626