[Build]: Support for toolchains for freestanding environments

[VzdornovNA88]

Problem.
It is not possible to use the library on common microcontrollers with arm cortex-m3/4 architecture.

In addition, the availability of support for such toolchains could help in correctly testing the CAN_STACK_DISABLE_THREADS flag, since only toolchains that do not define the standard C++ thread model can generate a compilation error and indicate a lack of consistency in the behavior of this compilation flag for all parts of the library.

Proposal
From my point of view, it is necessary to provide a cmake configuration file for such toolchains and verify the use of such platforms for all targets of building the library.

it also seems that we will need another pipeline with a set of such toolchains.

[VzdornovNA88]

@GwnDaan (lets take a look #647 ) So, in the process of experimenting with several toolchains, I came to the conclusion that building the isobus stack with these tools is an even broader problem than I thought at first glance, I had not previously used clang llvm to build for bare metal arm. In order to support more tools, I finally tried this toolchain, unfortunately my build host turned out to be a little old and I had to install an outdated toolchain for experimentation and implementation of the universal cmake build file, well, it turned out to be a really serious challenge, clang seemed more configurable and difficult to set up, but in the end, after successfully configuring the llvm toolchain.

I was disappointed that it did not provide many modules of the standard library, at least the version I used 13.0.0 . If gcc prohibits the use of streams in C++, then clang goes much further and does not implement support for atomic types, locale, system time library, and so on. Of course, developers working with bare metal environments may ask why they need all this and will be right to some extent, but my current goal was to provide the opportunity to build isobus libraries with these stripped-down toolchains, so I will temporarily turn off this voice and try to look from the point of view of the developers of the isobus library. Let's leave out the standard C++ threading model, which already knows how to disable in build, and we'll still have a lot of components that interfere with build, such as streams and atomic variables, as well as working with system time.

Well, these are freestanding environments that do not have an operating system by default or some kind of low-level environment that could provide them with all this, unfortunately, from the point of view of the standard, this is the case, it would be a mockery to require implementations to support all this functionality for all possible small RTOS and a large set of architectures and processors. Therefore, here I have to admit that clang 13.0.0 is unlikely to ever build this isobus library, mainly because of the scant support for the standard library of that version (I'm unlikely to talk about supporting different versions of libc++ on the same compiler), perhaps this could somehow be solved using the standard library from gcc, I haven't dealt with such combinations yet. Now about the good gcc, of course, everything is going well, if we take into account the PR, which solves the problem of properly disabling C++ threads (even my old version of gcc 10.2.1 arm-none-eabi, this triplet is mandatory here, because regular gcc is not like clang and does not know how to generate instructions for arm out of the box). But you can also say a few words about the setup - it differs for these two toolchains.

What is also important is that the toolchain file, in my opinion, should be able to detect which compiler is being used and configure accordingly.

The last thing I wanted to say is that I haven't finished with this toolchain file yet.

We have yet to create test environments for test builds for different versions of different compilers.

I assume that the latest versions of clang should work better, at least because the C++ standard does not stand still and regularly adds support for new modules of the standard library to freestanding.

This toolchain file is already ready to build programs that strictly comply with the requirements of freestanding environments, or with the help of gcc (ha ha).

Why I'm giving this PRs version is because I would like to understand which way to go next, whether CI support is possible here, whether anyone needs it at all, and such technical details as the API for using this build file, now there are several cmake build variables that I use to configure this toolchain file , but I don't like them, of course, the feedback and opinions of all participants would be valuable here.

Thank you.