[docs] suggestion: explicity remark that signals cannot be used from other threads

[liketechnik]

Using signals from another thread (e.g. set()) leads to the following error at runtime:

thread '<unnamed>' panicked at /home/florian/.cargo/registry/src/index.crates.io-6f17d22bba15001f/floem_reactive-0.1.0/src/signal.rs:274:39:
called `Option::unwrap()` on a `None` value
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I was able to resolve this using one of the methods from floem::ext_event. But that was only the case because: a) I already suspected using signals across multiple threads might not work b) the combination of "signal + thread" in GH's issue search lead to a PR mentioning the aforementioned create_signal_from_channel/update_signal_from_channel functions.

P.S.: floem has been a pleasure to use so far :)

[hydra]

I ran into the similar issues when attempting to get on a signal that was created in the callback from open_file(). In my case, I wasn't even aware that a second thread was being used by floem's open_file implementation. @jrmoulton spotted the problem and his solution was to create a signal in the main thread that the open_file callback uses and then have an effect, also in the main thread, that uses this signal when then creates the signal that was previously being in the callback.