sys: avoid zero fd

[lmb]

Upstream libbpf recently added code to avoid fds below three 1. The BPF
UAPI assumes in many places that a 0 value for fd means no argument was
provided. If stdin is closed by the program we can get a situation where
a BPF syscall returns a zero fd for a map, program or similar.

Add a similar mitigation, but restrict it to the zero value. This is because
the Go runtime already assumes that stderr is at the canonical fd 2:

Note that the Go runtime writes to standard error for panics and crashes;
closing Stderr may cause those messages to go elsewhere, perhaps to a
file opened later.

This means that a Go program fiddling with stdin, stdout, stderr already has
to at least account for this.

[ti-mo]

Nice! Why don't we return *sys.FD everywhere an fd int or uintptr is returned instead? I mean primarily sys.BPF, but the perf epoll stuff too, although those fds never go back into bpf(). Feels like we might want to avoid passing around bare fds without finalizers, they're pretty easy to leak.