libct/devices: move config to libct/cg/devices/config

[kolyshkin]

This is the next step to facilitate separation of libct/cgroups as per https://github.com/opencontainers/tob/blob/main/proposals/cgroups.md

Currently, libcontainer/devices contains two things:

1. Device-related configuration data structures and accompanying
   methods. Those are used by runc itself, mostly by libct/cgroups.

2. A few functions (HostDevices, DeviceFromPath, GetDevices).
   Those are not used by runc directly, but have some external users
   (cri-o, microsoft/hcsshim), and they also have a few forks
   (containerd/pkg/oci, podman/pkg/util).

This commit moves (1) to a new separate package, config (under
libcontainer/cgroups/devices), adding a backward-compatible aliases
(marked as deprecated so we will be able to remove those later).

(As for (2), I think something like moby/sys#181 should be done)

[kolyshkin]

So,

1. this CAN NOT be moved to libcontainer/cgroups (like we did with the rest of cgroups-related configs in libct/configs: move cgroup configs to libct/cgroups #4472) because some IDs (Type, Rule, Permissions) are too generic, and renaming them (to DeviceType, DeviceRule, DevicePermissions) will break backward compatibility (mostly due to Rulebeing embedded intoDevice`);
2. this CAN NOT be moved to libcontainer/cgroups/devices as it is a special package (importing it enables cgroup managers to manage devices (see https://github.com/opencontainers/runc/blob/main/libcontainer/cgroups/devices/devices.go) and makes binaries larger due to more dependencies like cilium/ebpf);
3. this CAN be moved to any other new package under libct/cgroups, e.g. libcontainer/cgroups/devconfig or something like this) -- please let me know it it's better than devices/config;
4. this COULD HAVE BEEN moved to libcontainer/cgroups/configs but in libct/configs: move cgroup configs to libct/cgroups #4472 we've decided to go without this package (although I should have thought about devices at that time, and I missed it).

So, it's either the way it is now in this PR, or we can break the backward compatibility and go with 1, or we go with 3.

WDYT @thaJeztah ?