Gate mod timespec on the net feature

[darkhonor]

Fixes #1689.

Both backends' sockopt modules reference crate::timespec unconditionally when handling SO_RCVTIMEO and SO_SNDTIMEO, but mod timespec was not gated in by net. Building with only net enabled fails with error[E0433]: cannot find timespecincrate``, six times through the linux_raw backend and three through libc. 1.1.4 was unaffected.

This reaches consumers that set default-features = false and opt into a minimal API surface rather than taking the defaults, which is the case that prompted the report.

net genuinely needs the module, so it is added to the gate rather than removing the uses. src/timespec.rs depends only on core, crate::backend::c and crate::ffi, so this pulls in no further feature-gated code.

Gating the sockopt timeout code instead would also compile, but would silently drop SO_RCVTIMEO and SO_SNDTIMEO support from a net-only build.

The --no-default-features job already checks time and time,use-libc individually; net and net,use-libc are added alongside them so the combination does not regress.

Verified on rustc 1.98.1 with the job's own RUSTFLAGS: -D warnings -D elided-lifetimes-in-paths:

features	before	after
net	6 x E0433	passes
net,use-libc	3 x E0433	passes
std,net	6 x E0433	passes
std,net,use-libc	3 x E0433	passes
std	passes	passes
std,fs	passes	passes
all-apis	passes	passes
all-apis,use-libc	passes	passes

[darkhonor]

Closing as a duplicate of #1681, which makes the identical one-line change and predates this by five days. I did not find it before opening this: I searched issues rather than open pull requests, which is my error. Credit for the fix belongs to @HalFrgrd.

The two check_no_default_features lines from this PR are offered as a comment on #1681 rather than as a competing change, for the maintainers to take or leave.