The error message if tun device creation failed can be misleading in containers

### What is the issue?

If tailscaled starts in tun mode, but the tun device creation failed, on linux clients we run a [diagnostic](https://github.com/tailscale/tailscale/blob/2aac91688883090d892f01a2953cc0318aee9c90/net/tstun/tun_linux.go#L22) to attempt to detect and log the potential cause.
A common cause for containerized deployments seem to be lack of permissions to read/write/create a tun device, see https://github.com/tailscale/tailscale/issues/10814 for context.
If that is the case, the first check that the diagnostic errors out on is `modprobe tun` [here](https://github.com/tailscale/tailscale/blob/2aac91688883090d892f01a2953cc0318aee9c90/net/tstun/tun_linux.go#L39), but on containers that would always error anyway (even if a tun device can be created) because containers typically don't mount host's `/lib/modules`, see

```
$ docker run -it --privileged tailscale/tailscale modprobe tun
modprobe: can't change directory to '/lib/modules': No such file or directory
```

so users end up seeing a slightly confusing error:

```
...
2024/12/04 14:52:44 wgengine.NewUserspaceEngine(tun "tailscale0") ...
2024/12/04 14:52:44 Linux kernel version: 5.15.0-1069-gke
2024/12/04 14:52:44 is CONFIG_TUN enabled in your kernel? `modprobe tun` failed with: modprobe: can't change directory to '/lib/modules': No such file or directory
2024/12/04 14:52:44 wgengine.NewUserspaceEngine(tun "tailscale0") error: tstun.New("tailscale0"): operation not permitted
...
```

We could perhaps check for read/write permissions to `/dev/net/tun` before the modprobe check.