iproute2 and libbpf: vendoring on the small scale

This all seems overwhelmingly easier to deal with than the Kubernetes vendoring problem. Ultimately, it means iproute2 needs to do what everybody has been doing all along: if the system libbpf lacks a feature, users don't get stuff that depends on that feature. And, new kernels come with a matching libbpf, because why wouldn't they?

The Kubernetes problem can be solved by treating all Golang programs as if they were scripts, and compiling them, with all their dependencies, at package installation time. (This is akin to what we already do when installing Elisp and Python modules, or kernel modules.) Then, a Golang library package just maintains a local repository shared among all the installed versions. The dependency annotations for each program package identify everything needed, so that installing a Golang program package would amount to fetching the all the right revisions to local repositories, checking them out, building, and then discarding the checkouts.

In fact the C compiler is also fast enough that libbfd and other fast-moving dependencies could be treated much the same way.