[Request]: expose seccomp in the API

### Feature or enhancement request details

Hi folks!

I'd like a way to specify a `noNewPrivileges: Bool` and a `seccomp: LinuxSeccomp?` property, so that callers of this library can pass those settings through to the OCI runtime spec that gets executed inside the VM.

Both fields already exist in `ContainerizationOCI` (`Process.noNewPrivileges` and
`Linux.seccomp`) — the missing piece is that the higher-level Swift API doesn't surface them, so library consumers have no way to set them.

My plan would be to have a way to set these attributes when generating the OCI image, and then on top of that make changes to the `apple/container` repo so that it makes good use of them, and expose it.

## Why this matters — the Dangerzone use case

[Dangerzone](https://github.com/freedomofpress/dangerzone) is a security tool from [Freedom of the Press Foundation](https://freedom.press) that converts potentially malicious documents (PDFs, Office files, images) into safe PDFs by processing them inside an isolated container. The threat model is explicit: the document being converted may be hostile, crafted specifically to escape the sandbox. Keeping the container process as locked-down as possible is therefore not optional — it is the whole point of the tool.

Dangerzone runs on Linux (Docker/Podman), and we've started experimenting `apple/container` support for macOS, which relies on this library. On every other container runtime it uses the following security flags unconditionally:

```python
security_args = ["--security-opt", "no-new-privileges"]
security_args += ["--security-opt", f"seccomp={seccomp_json_path}"]
security_args += ["--cap-drop", "all"]
security_args += ["--cap-add", "SYS_CHROOT"]
```

Without `noNewPrivileges` and a custom seccomp profile, a container process that is compromised by a malicious document could potentially escalate privileges or make syscalls that are not needed for legitimate rendering work, widening the attack surface. These two controls are the last line of defense after capability dropping.

Hope it makes sense! I believe we could add this behavior in a way that doesn't make changes to the default behavior, but I have limited understanding of the current codebase, and so let me know if I'm missing something!

Thanks!

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct