Allow custom input and output destinations

[Joannis]

This PR should address #13 , allowing us to communicate outside of stdin and stdout.

• startInBackground is added so that this library work with structured concurrency, and doesn't require the start to be top-level. In Structured concurrency, the main thread is already active and usable
• In addition, a new initializer and set of functions are exposed which allow input to come from an external source (SSH server), and output to be emitted in the same fashion.
• I should've put this in a separate PR, but \r is sent by the ssh client when pressing a button. I've made sure buttons can parse that input

An example implementation: https://github.com/orlandos-nl/Citadel/pull/65/files#diff-81bcbcd2ec23b21cc7b25d541760ca887a9e2819b67b7bbaa939bed4b83ef3df

[rensbreur]

Hi @Joannis, first of all thank you for your work!

These changes seem to be quite specific towards allowing SwiftTUI programs to be sent by a Swift server from a single server process as in your example (because from this issue it looks like using SwiftTUI over ssh already works). That requires the ability to override things such as (for now) how to write to the screen, how to get input and get window resize signals.

Regarding issue #13, snapshot testing would require more than just overriding this functionality, as the exact characters written to stdout will depend on implementation details, such as which exact parts of the screen are drawn when and which escape sequences are used to do that. It looks to me like it would be more useful to be able to just get an array of characters from the renderer to do snapshot testing and find out when a view is "ready" (but I don't want to make too large changes to include functionality into SwiftTUI that SwiftUI doesn't have either).

That is why I need to think about this some more before merging it into this main repository (of course I'm happy to help also with changes on your own fork). In the mean time here is some minor feedback regarding the specific code: (1) It seems that the SwiftTUI program still sets the input mode. (2) I indeed agree it might be useful to start a SwiftTUI program with an existing run-loop, I was thinking of adding an existing type to RunLoopType for this that does nothing, that wouldn't require a startInBackground function although it doesn't solve your issue of preventing a SwiftTUI app from registering for receiving events.