change in behavior from gnu-coreutils: leading optional positional args results in inability to process trailing options.

We've noticed a divergence in behavior in integration tests for rust-coreutils versus gnu-coreutils in how command line arguments are processed. This issue may represent a request for better broad handling of CLI argument processing to better align with glibc behavior.

For thedate command: gnu-coreutils is able to correctly process optional positional arguments whether or not they are in front of other valid command options.

• gnu-coreutils date succeed with either argument order, 1. leading date <format> <options> 2. trailing date <options> <format>

root@meh:~# date --version
date (GNU coreutils) 9.5
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.
(failed reverse-i-search)`date': ^Cte --version
root@meh:~# date  -d "Thu, 03 Nov 2016 00:47:00 -0400" "+%Z"
UTC
root@meh:~# date "+%Z" -d "Thu, 03 Nov 2016 00:47:00 -0400"
UTC

• rust-coreutils date cannot process trailing date command OPTIONS when the optional positional format argument is provided

root@meh:~# date --version
date (uutils coreutils) 0.6.0
root@meh:~# date  -d "Thu, 03 Nov 2016 00:47:00 -0400" "+%Z"
UTC
root@meh:~# date  "+%Z" -d "Thu, 03 Nov 2016 00:47:00 -0400"
date: extra operand '-d'
root@prepared-wasp:~# echo $?
1

Start with the date command's argument handling and the integration tests that compare rust-coreutils with gnu-coreutils. Reproduce both argument orders shown in the issue, then update the relevant handling so a format followed by valid options is accepted and verify the trailing-options case succeeds.