[feature] New logging system and refactoring in preparation for an intended stlink library approach

[Nightwalker-87]

This issue attempts to give STLink project a proper logging system in preparation for a library approach, to enable users incorporate stlink-lib into their projects.

What has already been achieved ✅ :

PRs #1497, #1501, #1504 --> already resolved the following points:

• The project may use libusb-cmake project as its libusb provider, which in turn allows for custom-built libusb, tailored to each system's needs. --> native libusb library project has been included into the compilation, if no package is available locally or from the respective sources.
• All included headers may be placed into appropriate stlink sub-folders that are included into the project as system includes, to allow for system-like includes. This change requires the change of all inclusions in the project to change from #include "%HEADER%.h" to #include <stlink/%HEADER%.h> --> a similar approach came into use. /stlink-lib now contains all library specific source and header files.
• Accommodate the appropriate cmake modifications for other BSD/*NIX based systems, as well as verify/implement a proper handling of pre-installed libusb followed by exhaustive testing --> this has been verified to the state already present

Proposal: Main changes (in a nutshell) and much needed prior additions that are missing:

• Several headers have exposed functionality which could be used by custom software, using extern "C" blocks.
• Changing the logging infrastructure to allow programmatically managed logging, instead of STDOUT logs.
• Documentation of the exported functions (and of course evaluate whether the overall exposure is excessive or too limited).
  This issue succeeds PR [withdrawn] New logging system in preparation for an intended stlink library approach #1437 in order to continue the open discussion.

[a-michelis]

Update:

I managed to borrow an STM32H753ZI from my work place and will start testing today.

Cheers!

---

Original Reply

As it stands I'm nearly done preparing the PR, but as my last STM32 Dev board got fried (its power distribution chip, to be exact), I lack the means to test it 😝

I'll push the latest changes later today into my fork and probably start a new PR to give others the chance to test it as well... The only thing I'm lacking right now is a way to incorporate the "file" output as a flag, within the tools (haven't dug deep enough to know how args are parsed)