feat: Update KubeArmor to use OCI hooks instead of depending on container runtime socket

[AbdelrahmanElawady]

Purpose of PR?: This PR utilizes OCI hooks to get container details inside KubeArmor instead of using container runtime socket. It depends on some Kubernetes annotations to get container name, pod name, namespace name and AppArmor profile (it looks like AppArmor is the only one required out of those but further testing is required). This PR also updates snitch to configure hooks on the host (currently only CRI-O is supported).

Fixes #1390

Does this PR introduce a breaking change? No, the goal is to have the same functionality as mounting container runtime socket without the security concerns of doing that.

If the changes in this PR are manually verified, list down the scenarios covered:: Tested with Getting Started example for now but more testing will be done.

Additional information for reviewer? :

• Containers created before KubeArmor was deployed is still not handled.

Checklist:

• [ ] Bug fix. Fixes #
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [x] This change requires a documentation update
• [x] PR Title follows the convention of <type>(<scope>): <subject>
• [ ] Commit has unit tests
• [ ] Commit has integration tests

[AbdelrahmanElawady]

Container created before KubeArmor now are handled with a simple detached process that waits on KubeArmor to start then sends all previous containers.

[AbdelrahmanElawady]

Also, in order to try out this PR. You only need to build this code and run it on a CRI-O Kubernetes cluster and operator with snitch will take care of setting up the cluster.