Add the LionsOS NFS fs_server as a second filesystem for ERTS

[schonfinkel]

Summary

Add the LionsOS NFS filesystem server (components/fs/nfs) as a second filesystem backend for beam_server, served over the 0.2.0 network stack, letting ERTS load modules and read/write files from a network share in addition to (or instead of) the local FAT disk.

Motivation

In and Around LionsOS highlights the network filesystem as the example consumer of the LionsOS "legacy layer" (an off-the-shelf library expecting POSIX-like read()/write()/send()), and ships components/fs/nfs for exactly this. A networked root is the realistic deployment for an appliance: central code/config distribution, no per-device disk image. It reuses the same lionsos.FileSystem protocol beam_server already speaks to FAT, so the BEAM side barely changes.

Proposed Solution

• Build the NFS fs_server (components/fs/nfs -> nfs.elf), which links the NFS client library against the LionsOS libc network/socket surface from 0.2.0.
• SDF: add the nfs PD in tools/sdf/system.zig via lionsos.FileSystem.init.
  • Same helper as FAT, connected to the network subsystem instead of block.
  • connect() + serialiseConfig(), objcopy its configs in mkSel4Image.
• Choose the mount model: NFS as the ERTS -root (fully networked), or mounted alongside FAT (FAT for boot, NFS for app data). Document the choice.
• Provide an NFS server for the test harness (a host-side nfsd/ganesha or a QEMU user-net NFS) so boot can resolve the share.
• Depends on 0.2.0 (network stack) and reuses the 0.1.0 fs-client plumbing.

Alternatives Considered

• Network-only (drop FAT): rejected (for now).
  • Keeping FAT for boot avoids a hard dependency on network availability at power-on.

Acceptance Criteria

• nfs.elf builds and boots as a PD, connecting to a test NFS share over the 0.2.0 stack
• ERTS loads at least one module from the NFS mount
• file write/read round-trips over NFS from the Eshell
• boot-smoke + shell-smoke green with NFS wired