Use "groupadd --system" to create group

# Bug report
I noticed instance generated from Debian bookworm cloud image on [linuxcontainer.org](https://linuxcontainers.org/) had odd GID=1000 for `netdev`. Since `netdev` should be a system group, this violates Debian policy https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes

> 100-999:
> Dynamically allocated system users and groups. Packages which need a user or group, but can have this user or group allocated dynamically and differently on each system, should use adduser --system to create the group and/or user. adduser will check for the existence of the user or group, and if necessary choose an unused id based on the ranges specified in adduser.conf.

I asked around to find the root cause of this problem:
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055700
* https://github.com/lxc/distrobuilder/issues/791

The conclusion was:
> It's listed as a default group in /etc/cloud/cloud.cfg which is the cloud-init config file.
>
> I suspect cloud-init just goes through the list and creates anything missing, but doesn't know if something is meant to be a system group rather than user group.
>

As I read https://cloudinit.readthedocs.io/en/latest/reference/modules.html#users-and-groups , this functionality of creating group is intended for system group.

For creating system group, `groupadd --system ` command should be used instead of `groupadd ` .

## Steps to reproduce the problem

On system with its `/var` on btrfs:
```
$ sudo apt install lxd
$ sudo lxd init --minimal
$ lxc launch images:debian/bookworm/cloud dbc
Creating dbc
Starting dbc
$ lxc exec dbc -- bash -l
root@dbc:~# tail /etc/group
systemd-journal:x:999:
systemd-network:x:998:
systemd-resolve:x:997:
input:x:102:
sgx:x:103:
kvm:x:104:
render:x:105:
_ssh:x:106:
netdev:x:1000:debian
debian:x:1001:
root@dbc:~# dpkg -l cloud-init
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-========================================================
ii cloud-init 22.4.2-1 all initialization system for infrastructure cloud instances
```
## Environment details
- Cloud-init version: 22.4.2-1 in Debian
c84369ac ("tests: Add logging fix (#4499)", 2023-10-12) -- in github has this issue
- Operating System Distribution: Debian
- Cloud provider, platform or installer type: linuxcontainers.org, lxd, Debian bookworm cloud image

## cloud-init logs
N/A

## Possible fix

Quick reading of the source code, this issue may be resolved conceptually by applying the following patch
(Please note I have not tested this.)
```
From 17fd94ee214d2e0784250b74144f0b236773c0cf Mon Sep 17 00:00:00 2001
From: Osamu Aoki
Date: Sat, 11 Nov 2023 12:06:07 +0900
Subject: [PATCH] Fix with --system

Signed-off-by: Osamu Aoki
---
cloudinit/distros/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cloudinit/distros/__init__.py b/cloudinit/distros/__init__.py
index 87390f63..72109ccd 100644
--- a/cloudinit/distros/__init__.py
+++ b/cloudinit/distros/__init__.py
@@ -1082,7 +1082,7 @@ class Distro(persistence.CloudInitPickleMixin, metaclass=abc.ABCMeta):
raise e

def create_group(self, name, members=None):
- group_add_cmd = ["groupadd", name]
+ group_add_cmd = ["groupadd", "--system", name]
if util.system_is_snappy():
group_add_cmd.append("--extrausers")
if not members:
--
2.39.2
```

## Concerns

The above patch didn't consider impacts and compatibility to some Ubuntu environment addressed by the subsequent ` if util.system_is_snappy()` condition. This `-extrausers` seems to be a Ubuntu specific feature.

It looks like `create_group` is only used from `cc_users_groups.py` for processing `groups`. If other parts use this too, their impacts need to be assessed.

## Possible benefits for existing issue reports

I see some issues reported around this here:

* https://github.com/canonical/cloud-init/issues/2314
* https://github.com/canonical/cloud-init/issues/2503

These issues are practically resolved by making proper system group ID assignment with the proposed fix because they are looking for GID=100-999 for system group. Then odd situation of primary user having UID=1000 GID=1001is avoided.