grant access to unprivileged containers to the kubelet podresources socket

Description of problem:
containerized workloads running as container_t wants to connect to the kubelet podresources API through a unix domain socket sitting at `/var/lib/kubelet/pod-resources/kubelet.sock`

Both `/var/lib/kubelet/pod-resources/kubelet.sock` and `/var/lib/kubelet/pod-resources/kubelet.sock` are currently labeled as `container_var_lib_t`.

They should probably treated as device plugins

This is specially important to enable the numa-aware scheduler (

Version-Release number of selected component (if applicable):
selinux-policy-38.1.8-1.el9.noarch
selinux-policy-targeted-38.1.8-1.el9.noarch
container-selinux-2.199.0-1.el9.noarch

How reproducible:
100%

Steps to Reproduce:
1. run unprivileged container, mount the kubelet podresources socket (see attached example yaml)
2. try to access to the podresources socket. Example test client available at https://github.com/k8stopologyawareschedwg/podresourcesapi-tools/releases/tag/v0.0.1 - `podrescli --podresources-socket unix:///host-podresources-socket/kubelet.sock`
3.

Actual results:
avc denials:
```
type=AVC msg=audit(1679405027.674:79402): avc: denied

{ write } for pid=2236325 comm="podrescli" name="kubelet.sock" dev="sdb4" ino=144703618 scontext=system_u:system_r:container_t:s0:c25,c26 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=sock_file permissive=0
type=AVC msg=audit(1679405031.376:79403): avc: denied { write }

for pid=2236496 comm="podrescli" name="kubelet.sock" dev="sdb4" ino=144703618 scontext=system_u:system_r:container_t:s0:c25,c26 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=sock_file permissive=0
type=AVC msg=audit(1679405032.046:79404): avc: denied

{ write }

for pid=2236590 comm="podrescli" name="kubelet.sock" dev="sdb4" ino=144703618 scontext=system_u:system_r:container_t:s0:c25,c26 tcontext=system_u:object_r:container_var_lib_t:s0 tclass=sock_file permissive=0
```

Expected results:
access should be granted

Additional info:
at the moment we are using a custom policy. We can keep using this a stopgap fix. The policy is also broken with the above package

policy: https://github.com/k8stopologyawareschedwg/deployer/blob/main/pkg/assets/rte/selinuxpolicy-ocp411.cil
denials:
```
type=AVC msg=audit(1679044968.338:5383): avc: denied

{ connectto }

for pid=10664 comm="resource-topolo" path="/var/lib/kubelet/pod-resources/kubelet.sock" scontext=system_u:system_r:rte.process:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=unix_stream_socket permissive=0
```
In that (different nightly though) system the label was
```
srwxr-xr-x. 1 root root system_u:object_r:container_var_lib_t:s0 0 Mar 15 22:02 /var/lib/kubelet/pod-resources/kubelet.sock
```