RFR: 8347129: cpuset cgroups controller is required for no good reason

[Severin Gehwolf]

Please review this small change to make the `cpuset` cgroups controller optional as far as the JDK is concerned. The rationale is that:

- Some distributions now don't have it enabled by default (e.g. Fedora 41), which breaks automatic container detection logic.
- CPU limits enforced with `--cpuset-cpus` is reflected with the `sched_getaffinity` system call and, thus, the controller doesn't need to be mandatory. The current failure to detect the controller results in no container limits being detected with is bad.

The fix is rather simple. Make `cpuset` controller look-up from `/proc/cgroups` optional (like the `pids` controller) and continue. `OSContainer::active_processor_count()` still behaves as before (should there be a `cpuset` limit) as it's covered by `os::Linux::active_processor_count()` which serves as the upper bound of other container cpu limits.

While at it, I've also fixed the logging bug by re-arranging the `const char*` values. `cpuset` is index `0`, `cpu` is index `1`.

Testing:
- [ ] GHA
- [x] Linux container tests in `test/hotspot/jtreg/containers` on Linux cgroups v1 and cgroups v2 as well as on an affected system (F41 on cg v2). All pass.

Thoughts?

-------------

Commit messages:
 - Fix comment
 - 8347129: cpuset cgroups controller is required for no good reason
 - Fix container logging bug (mentions 'cpu' while it should be 'cpuset')

Changes: https://git.openjdk.org/jdk/pull/23037/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23037&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347129
  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/23037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23037/head:pull/23037

PR: https://git.openjdk.org/jdk/pull/23037