Problem with path search in `upsdrvctl` WIN32 builds

[jimklimov]

Bypass upsdrvctl (Bug Workaround): The upsdrvctl start command consistently failed with a misleading No such file or directory error. Debugging revealed it was likely due to a bug in how upsdrvctl.exe constructs paths on Windows/MSYS2 (it tried to run C:\msys64\ucrt64\sbin//ucrt64/bin/nutdrv_qx.exe.exe at one point).

Workaround: Launch the driver directly instead of using upsdrvctl.

Originally posted by @andresg97 in #2881

[jimklimov]

Hm, at least with a build from "MSYS2 MinGW x64" profile, I could not reproduce the problem with upsdrvctl, running from the build workspace with an amended copy of config from #2881 stored in drivers/etc/ups.conf (so it is in ../etc when searched by driver programs built into drivers/.libs):

• Without a driverpath in ups.conf the built-in paths worked somehow, it found the program name in same directory as upsdrvctl.exe I suppose:

:; NUT_DEBUG_LEVEL=6 ./drivers/upsdrvctl start forza_fx1500
...
   0.031367     [D1] upsdrvctl commanding one driver (forza_fx1500): start
   0.033854     [D1] Starting UPS: forza_fx1500
   0.037052     [D2] 1 remaining attempts
   0.038477     [D2] exec:  C:\msys64\home\klimov\nut-win\drivers\.libs/nutdrv_qx.exe -a forza_fx1500
Defaulting debug verbosity to NUT_DEBUG_LEVEL=6 since none was requested by command-line options
   0.005079     [D5] send_to_all: SETINFO driver.state "init.starting"
Network UPS Tools 2.8.2.2725-2725+g90c75da1b (development iteration after 2.8.2) - Generic Q* USB/Serial driver 0.42
USB communication driver (libusb 0.1) 0.50
   0.016871     [D1] upsdrv_makevartable...
...

• Using driverpath=/home/klimov/nut-win/drivers/.libs I got an error, probably from the underlying system exec method. :

... Can't start /home/klimov/nut-win/drivers/.libs/nutdrv_qx.exe: No such file or directory [The system cannot find the path specified. ]

• Using driverpath=c:/msys64/home/klimov/nut-win/drivers/.libs it also worked well, same as above.

So in no case did it concatenate a Windows path with a Unixish msys2 path.

MAYBE the issue is UCRT64 specific...

CC @andresg97