Align procedure for OS Image Build with security best-practices

**What happened**:
The EKS Anywhere documentation does the following
1/ makes recommendation to modify the default filesystem permissions
Referencing the Build Bare Metal Node Images page as an example:
https://anywhere.eks.amazonaws.com/docs/osmgmt/artifacts/#build-bare-metal-node-images
The doc recommends the following
```
sudo chmod 666 /dev/kvm
sudo chown root:kvm /dev/kvm
```

Originally the file has the following permissions (Ubuntu 20.04 as an example)
```
~$ ls -l /dev/kvm
crw-rw----+ 1 root kvm 10, 232 Mar 14 15:28 /dev/kvm
```

Places that would require an update (filename in output)
```
$ grep -r "chmod 666" *
docs/content/en/docs/osmgmt/artifacts.md: sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md: sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md: sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md: sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md: sudo chmod 666 /dev/kvm
docs/content/en/docs/osmgmt/artifacts.md: sudo chmod 666 /dev/kvm
```

Note: a widely recognized "work around" to simply run `newgrp kvm` which allows the image-bulder user to then access /dev/kvm - but this is not ideal, either. If the user runs the `newgrp kvm` command, all new files created after that point will have group-ownership of kvm. This may not be a bad scenario though.

2/ Provides steps for user management for user:image-builder introduces a number of challenges - which happen to have OS-specific solutions. I.e. group `sudo` exists in Ubuntu, but not RHEL.

This either requires some sort of `case statement` to determine current OS, or move the user management steps to the OS-specific tabs in the instructions.

**What you expected to happen**:
I believe a better approach should be identified and the documentation updated.
This likely will mean that the /dev/kvm flie is not modified, and the image-builder user will need to logout/login for the shell to recognize that image-builder belongs to the kvm group.

**How to reproduce it (as minimally and precisely as possible)**:

**Anything else we need to know?**:

**Environment**:
- EKS Anywhere Release:
- EKS Distro Release:

Start with docs/content/en/docs/osmgmt/artifacts.md and search it for every `chmod 666` occurrence. Review the existing user-management instructions and OS-specific tabs, then determine how the kvm group and image-builder setup should be documented without weakening /dev/kvm permissions. Done means the procedure consistently follows safer permissions and accounts for the Ubuntu and RHEL differences.

Written by the indexing model from the issue text.