Freertos port

[mokshasoft]

Here is a multi-threaded port of Idris C RTS to FreeRTOS. Here is an example of this port running on a versatilepb platform in QEMU, https://github.com/mokshasoft/FreeRTOS-community-ports/blob/master/Demo/ARM926ejs-GCC-Idris/README.md The demo starts three threads; on printer that only prints, and one sender that sends data via a queue to a receiver thread. Here is a log of the execution:

Hello, Idris Unikernel
Printing from printer..
sender and receiver started
sending 123
received: 123
sending 123
received: 123
Printing from printer..
sending 123
received: 123
Stopping receiver thread
Stopping sender thread
Printing from printer..
Printing from printer..
Printing from printer..
Stopping printer thread

I have run 'make test' with and without the patches and in both cases two test-cases fail. The branch which I ran the tests on is master with patch:
1dd9316 Compatibility with GHC 8.8 and Cabal 3.0
reverted. Building a clean master on my Fedora 31 failed. I ran git bisect and it pointed to that commit.

In idris_rts.c I have removed the sprintf dependency in the last patch. I don't know what you think about that? sprintf handles very complicated format strings, but is only needed to cast integers to strings. I think the new implementation is way faster than the previous one. The build of Idris/FreeRTOS is not using libc, that's why I wanted to replace the calls to sprintf. I could put them under the BARE_METAL ifdef is you think that is better?

I will also contribute the Idris interface towards FreeRTOS to the contrib package, but first I want to get the RTS plumbing in.

[mokshasoft]

I moved the ftoa implementation under the BARE_METAL flag since it performed rounding differently compared to snprintf. When I ran the test cases on my machine it reported 2 errors, but the CI reported 5. Testing the master branch on my machine resulted also in 2 errors, so I thought that my patches hadn't broken anything. I don't understand the difference though.

[melted]

Thanks for the PR!

I think that's the right decision, we should keep snprintf for the platforms that supports it.

I'll get around to reviewing it soon.