Add target group as first gid when specified

[bjorn3]

On FreeBSD the first gid in the setgroups list is the effective gid. And the groups list should contain this gid a second time to avoid losing it when running a setgid program according to the man page of setgroups.

This somehow causes the group in when_specified_more_than_once_all_groups_are_added_to_group_list to be duplicated. I can't check correctness of this duplication against original su as on FreeBSD su doesn't provide an option to specify groups.

This fixes the following test failures:

---- su::flag_group::when_specified_more_than_once_all_groups_are_added_to_group_list stdout ----
thread 'su::flag_group::when_specified_more_than_once_all_groups_are_added_to_group_list' panicked at sudo-compliance-tests/src/su/flag_group.rs:84:5:
assertion `left == right` failed
  left: "1001 1000"
 right: "1001"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- sudo::flag_group::adds_group_to_groups_output stdout ----
thread 'sudo::flag_group::adds_group_to_groups_output' panicked at sudo-compliance-tests/src/sudo/flag_group.rs:74:9:
assertion failed: `(left == right)`

Diff < left / right > :
 {
<    "users",
     "secondary-group",
>    "ferris",
>    "users",
 }

Part of #869

[squell]

I'm fearful of the added complexity of making the request group into an Option, especially as this impacts the permission checker (by the time it runs the requested group has to be completely figured out). And it also doesn't solve the issue when someone is running -u user -g user (we're still non-compliant with these changes).

But I think the .insert instead of .push is onto something.

[squell]

Option<Group> should not really be in the context object

[squell]

So on BSD, setgroups expect the first argument to be the effective GID, which also means a subsequent call to setgid will overwrite it; that causes the tricky behaviour here.

[bjorn3]

Closed in favor of #937