build(deps): bump github.com/containerd/cgroups/v3 from 3.0.2 to 3.0.3

Bumps [github.com/containerd/cgroups/v3](https://github.com/containerd/cgroups) from 3.0.2 to 3.0.3.
- [Release notes](https://github.com/containerd/cgroups/releases)
- [Commits](https://github.com/containerd/cgroups/compare/v3.0.2...v3.0.3)

---
updated-dependencies:
- dependency-name: github.com/containerd/cgroups/v3
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

vendor/github.com/cilium/ebpf/CONTRIBUTING.md

@@ -5,15 +5,23 @@ the form of pull requests and issues reporting bugs or suggesting new features
 are welcome. Please take a look at [the architecture](ARCHITECTURE.md) to get
 a better understanding for the high-level goals.
 
-New features must be accompanied by tests. Before starting work on any large
-feature, please [join](https://ebpf.io/slack) the
-[#ebpf-go](https://cilium.slack.com/messages/ebpf-go) channel on Slack to
-discuss the design first.
+## Adding a new feature
 
-When submitting pull requests, consider writing details about what problem you
-are solving and why the proposed approach solves that problem in commit messages
-and/or pull request description to help future library users and maintainers to
-reason about the proposed changes.
+1. [Join](https://ebpf.io/slack) the
+[#ebpf-go](https://cilium.slack.com/messages/ebpf-go) channel to discuss your requirements and how the feature can be implemented. The most important part is figuring out how much new exported API is necessary. **The less new API is required the easier it will be to land the feature.**
+2. (*optional*) Create a draft PR if you want to discuss the implementation or have hit a problem. It's fine if this doesn't compile or contains debug statements.
+3. Create a PR that is ready to merge. This must pass CI and have tests.
+
+### API stability
+
+The library doesn't guarantee the stability of its API at the moment.
+
+1. If possible avoid breakage by introducing new API and deprecating the old one
+   at the same time. If an API was deprecated in v0.x it can be removed in v0.x+1.
+2. Breaking API in a way that causes compilation failures is acceptable but must
+   have good reasons.
+3. Changing the semantics of the API without causing compilation failures is
+   heavily discouraged.
 
 ## Running the tests
 
@@ -35,6 +43,6 @@ Examples:
 ./run-tests.sh 5.4
 
 # Run a subset of tests:
-./run-tests.sh 5.4 go test ./link
+./run-tests.sh 5.4 ./link
 ```