Toolbox can't start if user has any group-only permissions for device nodes in folders

**Describe the bug**
If a user is a member of any group that grants access to device nodes in folders that have `750` permissions, all `toolbox`es can no longer be `enter`ed.

For example when VirtualBox is installed, the `/dev/vboxusb/*` device nodes are created with `750` permissions on both the folder and the files, and they're owned by the `vboxusers` group (this behavior is consistent with standards for device node permissions, and is like the `/dev/ttyUSB*` nodes on Fedora systems). Toolbox maps the entire `/dev` into the container, which uses the user permissions from outside the container to map all visible files into the container. The `crun` mapping of sub-folders uses the permissions inside the container namespaces to create a matching folder however. This causes an error because the folder has permissions granted only via an unmapped group.

TL;DR
Blanket mapping of `/dev` into the container without also mapping all the user's groups breaks in very common conditions.

**Steps how to reproduce the behaviour**
1. Create device node in a folder with `750` permissions, owned by a group the user is part of but not by the user directly.
1. `sudo mkdir -Z -m 750 /dev/testFolder`
2. `sudo mkdnod -Z -m 750 /dev/testFolder/testNode b 7 30` (loop device 30)
3. `sudo chown -R root:dialout /dev/testFolder` (`dialout` used for convenience rather than
creating a new group)
4. `groups`, and confirm user is part of `dialout` group
5. `ls /dev/testFolder`, confirm the user can see the files using the `dialout` group permissions
2. `toolbox create`
3. `toolbox enter`

**Expected behaviour**
Toolbox is entered successfully.

**Actual behaviour**
Error, unable to enter toolbox.
```
Error: unable to start container XXXX: crun: mkdir `/dev/testFolder`: Permission denied: OCI permission denied
```

**Screenshots**

N/A

**Output of `toolbox --version` (v0.0.90+)**
```
toolbox version 0.0.99.4
```

**Toolbox package info (`rpm -q toolbox`)**
```
toolbox version 0.0.99.4
```

**Output of `podman version`**
```
Client: Podman Engine
Version: 4.6.0
API Version: 4.6.0
Go Version: go1.20.6
Built: Fri Jul 21 08:23:26 2023
OS/Arch: linux/amd64
```

**Podman package info (`rpm -q podman`)**
```
podman-4.6.0-1.fc38.x86_64
```

**Info about your OS**
Fedora Kinoite 38

**Additional context**

The issue becomes immediately very obvious if you install `VirtualBox`. This creates `/dev/vboxusb/*` USB proxy device nodes, where the `/dev/vboxusb` and all contents are owned by the `vboxusers` group. If the user isn't part of the `vboxusers` group, `toolbox` works because the folder doesn't appear to be present under the user permissions. But if the user is a member of the group (as can be expected), the folder can be listed from outside the container, but the permissions for interacting with it inside the container namespace aren't available to `crun`.

---

The only viable solutions are:
1. Stop mounting `/dev` as a whole into the container and instead iterate over all device nodes found recursively from outside the container, filtered down to the ones owned directly by the user or with `755` permissions.
2. Use `--group-add keep-groups` and have `toolbox init-container` inside the container create the necessary matching groups/gids that are added to the user in the container.
3. Allow a an option to `toolbox create`, `--keep-group={group_name}`, that can list multiple groups that should be mapped from the host user into the container. Allow a default list to be specified in the `toolbox.conf`.

The second option is obviously much better than 1 since it solves a number of other complaints (e.g. `/dev/ttyUSB*` access), but has the negative effect that the list of group names to gids from the user outside the container must be replicated inside the container, and traceability of what those were must be kept inside the container so if a user is removed from a group they will also be removed from the group inside the container.

Option 3 is probably the best though, since it allows the current existing behavior as-is, but also allows users to specifically pass thru certain group permissions. It would suffer from the same complexities as option 2 in terms of implementation though, and would add the need to parse extra command-line options and config file fields.

Reproduce the failure with a group-owned `/dev/testFolder` and run `toolbox create` followed by `toolbox enter`. Start by tracing Toolbox's `/dev` mapping, the `toolbox init-container` entry point, and the handling of `--group-add keep-groups`; review `toolbox.conf` only if configuration support is needed. Done means entering a toolbox succeeds when device-node access comes from a supplementary group, with coverage for the reported scenario.

Written by the indexing model from the issue text.