Fix use-after-free of FSocketIONative from its own game-thread callbacks

[marekl11]

SetupInternalCallbacks() marshals each internal listener (connect/disconnect/ namespace/fail/reconnect) onto the game thread via RunShortLambdaOnGameThread, and those lambdas captured the FSocketIONative by reference. The deferred task lives on the game-thread task graph independently of the object, so if the native client is released before the task runs, the lambda dereferences freed memory.

This reproduces during a UE level transition: tearing down the old world releases the client on a background thread, and LoadMap's own FlushRenderingCommands then pumps the game-thread task graph and runs the stale callback. Observed as an access violation reading 0xffffffffffffffff on the game thread, top frame being the namespace-disconnect lambda.

FSocketIONative now derives from TSharedFromThis and each deferred lambda captures a TWeakPtr and Pin()s it, so it no-ops if the object is already gone. A weak (not strong) capture avoids extending the object's lifetime and moving its destruction (which joins the network thread) onto the game thread. This is the same class of fix as the component-level weak-pointer guard, one layer down at the native object.

The shared-pointer mode has to be ESPMode::ThreadSafe because the object can be released on a background thread while the lambda runs on the game thread, so the refcount must be atomic; the handful of TSharedPtr in the module API change accordingly (README example updated to match). The outer asio-thread listeners intentionally keep their [&] capture: PrivateClient is the last member, so ~FSocketIONative destroys it first and the network thread is joined before the other members are torn down.