`containerized` detection isn't reliable

The logic for detecting whether `go-sysinfo` in running inside a container isn't always correct.
The code section is: https://github.com/elastic/go-sysinfo/blob/6057d34798d93384013c2e8f8e3bd0b00c599912/providers/linux/container.go#L48-L52

and we can see that e.g. on a Linux host with cgroupsv2 we have:

```
[root@164502a64991 /]# cat /proc/1/cgroup
0::/
```

which isn't covered by the above code.

We aren't the only ones who've noticed this discrepancy, as we can see in the [linked stack overflow](https://stackoverflow.com/questions/20010199/how-to-determine-if-a-process-runs-inside-lxc-docker/20012536#20012536) article.

The truth is that detecting containerization isn't very straightforward. For example Puppet's facter seems to [only detect docker](https://groups.google.com/g/puppet-bugs/c/ApU9R9TN3lQ) but not e.g. when running in `podman`. Issues have also been reported with Chef's Ohai ([example](https://github.com/chef/ohai/issues/1026)) that seem to be resolved. A succinct comment with the possible strategies can be found in https://github.com/benfred/py-spy/issues/614.

Ohai's implementation seems to be the most complete, so we could get some ideas from https://github.com/chef/ohai/blob/d63ae8e8af713c44d040f5583aac84cd3d79f9af/lib/ohai/plugins/linux/virtualization.rb#L180-L217

Read providers/linux/container.go at lines 48-52 and reproduce the cgroupsv2 example showing /proc/1/cgroup as 0::/. Compare the possible detection strategies linked in the issue, especially Chef Ohai's Linux virtualization implementation. Done means container detection covers the reported case and accounts for the documented runtime differences, including podman.

Written by the indexing model from the issue text.