[feature] libusb-cmake as libusb provider and added support for MSVC

[a-michelis]

Overview

This pull request alters Findlibusb.cmake in order to add proper Windows MSVC handling. It discards the old MINGW approach and uses the libusb-cmake repository as the main provider instead for both Windows and Linux. As it stands now, if libusb is not installed for these two OSes, the libusb-cmake repository is being cloned and incorporated into the build. This way,stlink has a freshly built libusb, tailored to the system's configuration and needs, installed into the same INSTALL_PREFIX as stlink.

Additionally, this pull request adds Windows/MSVC support into the c/c++ github workflow.

Potential issues

1. In Windows, there is a possibility that the installation path for all LIBRARY items must be the same as the one of RUNTIME items, as opposed to the Linux paradime, where LIBRARY and ARCHIVE items are the ones that share location. This needs further investigation and potentialy a complementary fix, as I currently have no equipment and a clean environment to test it. I'll get back to it once I manage to prepare the proper testing ground.

2. One very important note on this PR is that it probably drops support for MINGW. If mingw is still needed I'm going to need assistance, Since I've never worked with it in the past and i do not know how to properly validate such builds.

(Closes #1424)

[Nightwalker-87]

Please solely introduce changes affecting the windows operating system due to the package-based nature of unix-based systems to ensure the verification of system integrity.

[a-michelis]

Tested the MSVC Build and it needs some additional root cmake modifications to work, but totally easy to do. Will come back with them sometime later today.

As for the library part, This is something that cannot be brought to this PR, since it requres restructuring in both code and CMAKE:

• Since windows have their own usb.h, it conflicts with stlink's header and, thus, it's required to put the headers within a prefixed subfolder and use them as such (ie #include <stlink/usb.h>). This requires code modifications, as all headers that have #include <someStlinkHeader.h> must be converted to #include <stlink/someStlinkHeader.h>.

• Windows require __declspec(dllexport/dllimport) to each desired function, in order to properly export functionality. This is solvable by creating an stlink/api.h header with the well-known macro definition (let's call it STLINK_API), that prepends dllexport when building and dllimport when using (via compiler definition). That's easy to address- essentially a templated copy-paste-edit snippet.

[Nightwalker-87]

I consider this a good and very useful contribution, with only a few remaining FMPOV accountable remarks that should be easily addressable. Thank you very much. 👍

[Nightwalker-87]

@a-michelis: Sorry for the delay. Having swapped hardware recently, I needed some time last WE to finalise the setup of my working environment...
What came to my mind is that we should have a small description in our compiling manual (doc/compiling.md), but I can take cake of that afterwards. However some notes on how to proceed in the original issue could be helpful, I guess.

[a-michelis]

What came to my mind is that we should have a small description in our compiling manual (doc/compiling.md), but I can take cake of that afterwards. However some notes on how to proceed in the original issue could be helpful, I guess.

@Nightwalker-87: I totally agree, It won't take much to add some compilation guidance to compiling.md.
I believe I can allocate some time at 26/12 and have it committed by the end of that day!

Small Context & suggestion:
As it is now, Compilation for MSVC uses solely CMAKE commands (CMAKE uses the installed msvc compiler).
It is my understanding that the provided makefile is a wrapper to the appropriate CMake Commands. If my understanding is correct, unifying the testing methodology in all OSes (in C/C++ Workflow) to use cmake would be a good practice imho. That would be a separate PR of course, but I leave it here as food for thought.

[a-michelis]

I'm sorry for being late on my promise, Holidays got the better of me! Added the compilation manual, as discussed!

[Nightwalker-87]

It is my understanding that the provided makefile is a wrapper to the appropriate CMake Commands. If my understanding is correct, unifying the testing methodology in all OSes (in C/C++ Workflow) to use cmake would be a good practice imho. That would be a separate PR of course, but I leave it here as food for thought.

True, surely a good attempt. Maybe one may update and reuse the other Draft-PR for this.

Thanks again for your valuable contribution @a-michelis. I believe we are now ready to merge.