core/vfs: carry the caller's supplementary groups in Context

[jiangliu]

The FUSE device reports only the caller's uid, its primary gid and -- for create-family requests -- the single group of the FUSE_EXT_GROUPS extension, so a server running a passthrough file system behind a local /dev/fuse mount can resolve the caller's full supplementary group list from /proc//status. That escape hatch does not exist for remote transports such as virtiofs: the pid is a guest pid with no meaning on the host, and permission checks that should honor supplementary groups silently degrade to uid/gid only.

Give Context an optional supplementary group list that a transport or embedding VMM can inject with the request, to be used directly instead of a /proc lookup. The field is purely additive plumbing in this change: the ordinary request path leaves it None, and passthrough consumption (thread cred switching) is a separate follow-up.

Carrying a Vec means Context can no longer be Copy, so the five VFS create-family entry points and the passthrough async_relay macro now clone the context instead of dereferencing it, and the struct-literal tests gain ..Default::default().

With a VFS id mapping configured, remap_ctx_ids() now translates the list to internal (host) ids together with uid/gid, using the same policy as the existing supp_gid translation: groups inside the mapped range are translated, groups outside it have no legitimate host counterpart and are dropped, so a guest can never make the daemon adopt an arbitrary host group. The arithmetic mirrors remap_id() so reverse-direction mappings don't underflow.

Ported from PR #220 ("Add supplementary groups support and POSIX permission fixes").