Use "new mount API" if available

bubblewrap currently uses the traditional `mount(2)` API for everything. This is not a great interface for container'y use cases.

In particular, the mount(2) API has the problem that it is path-based rather than fd-based, requiring some strange and non-robust code to implement `--[ro-]bind-fd` (which is necessary for Flatpak and other sandboxing frameworks that operate on attacker-controlled directory hierarchies, which need to use `--[ro-]bind-fd` to avoid vulnerabilities like CVE-2024-42472 and CVE-2026-34078).

If we use the "new mount APIs", it should be possible to implement `--[ro-]bind-fd` with `open_tree(..., AT_EMPTY_PATH | OPEN_TREE_CLONE | AT_RECURSIVE)` followed by `mount_setattr()` and `move_mount(..., MOVE_MOUNT_F_EMPTY_PATH)`, similar to some of the examples in [open_tree(2)](https://manpages.debian.org/testing/manpages-dev/open_tree.2.en.html).

Similarly, `--{,dev-,ro-}bind-fd` could be implemented in a similar way, but starting from `AT_FDCWD` and an absolute path, rather than a fd and `AT_EMPTY_PATH`.

On older kernels, none of this would work (`ENOSYS` or `EINVAL`), and we'd have to fall back to the way things are currently done.

#754 should probably be done first - that's a much simpler use of the "new mount APIs".

A possible follow-up would be to increase the minimum kernel version to one that implements all of the necessary syscalls, but (like #754) that would mean abandoning the ability to run bubblewrap (and therefore Flatpak, the Steam Runtime, etc.) on older distros like RHEL 8 and Ubuntu 20.04, which is something we have historically tried hard not to do. If that is done, then I think it should be a separate PR and a separate issue.

[Tracked as steamrt/tasks#1005 elsewhere]

cc @ao2