crypto/tls: use Go's software TLS on the host target

[0pcom]

TinyGo's crypto/tls is a thin wrapper around a netdev-provided (hardware/firmware-offloaded) TLS socket, which only exists on the embedded/wasm targets that have such a netdev. On the host/native target the netdev is raw syscalls with no TLS offload, so crypto/tls could never actually work there. Link Go's full software crypto/tls on the host instead, keyed off needsSyscallPackage (true exactly for the embedded/wasm targets, which keep the offload wrapper unchanged).

Go's crypto/tls needs one runtime hook TinyGo lacked: weak.runtime_makeStrongFromWeak (Go 1.24 weak pointers). Added next to the existing registerWeakPointer as a strong-reference no-op — weak pointers are never collected here, so the referent is always alive.

Verified on linux/amd64 (LLVM 22): a real TLS 1.3 handshake and HTTPS round trip entirely in-process — tls.Client against an http.Server behind a TLS listener over loopback — plus external curl -k against the same server. Pairs with tinygo-org/net#79 (net/http.ListenAndServeTLS/ServeTLS), but is independently useful for any crypto/tls client use.

🤖 Generated with Claude Code

https://claude.ai/code/session_01C3X3gvq8ZggMRvzVzWm66i

[yohimik]

This overlaps #5633 for the weak hook and #5635 for hosted software TLS. I am removing the copied weak commit from #5635 so that each change has one patch in our series. Could we use #5633 for the hook and agree on one loader PR? #5635 includes loader target-selection tests and a handshake test that rejects an unknown CA. Its selection is limited to hosted Linux and Darwin. This PR uses needsSyscallPackage, which also selects other hosted targets, so the two guards need a target-by-target check before consolidation. The tests and downstream client evidence in #5635 are available for either approach. I will not change your branch.