fix(core): Replace Rc with Arc to prevent crashes when sending events

[FabianLars]

I feel like this is more of a workaround than a fix but this reduced the crashes on macos for me. That said, the issue i was trying to fix was on windows but when i worked on this commit i couldn't repro it with and without this change. The issue seems to be influenced by available system resources or something because it's not the first time i wasn't able to reproduce it.

This may close #8177 but i'd like @i-c-b and/or @JJeris to try it out (since they were able to reproduce it more reliably than me).

p.s. i don't think i'm capable enough of doing so but we should still find out what's actually happening here or alternatively change the types so that clippy doesn't complain about Arc when it's actually needed (if possible).

[JJeris]

What was this workaround? The iterator or the new thing discovered by the other user?
Ill test it out today, if i can.

[i-c-b]

This seems to fix the issue for Linux. On Windows, it seems that emitting more than 12725 events at time causes emit to fail with runtime error: failed to send message to the webview; unsure what's going on there.

event-flooder crashes with v1.5.2, v1.5.3, and the bleeding-edge 1.x branch which includes the clipboard changes. All had nearly instant crashes when I tried 1,000,000 events. The moment I switched to the event-crash branch, the crashing stopped and I could no longer reproduce it no matter how many events I emitted.

What was this workaround? The iterator or the new thing discovered by the other user?

In Tauri v1.5.0, the event system switched from std::sync::Arc to std::rc::Rc. This workaround reverts that change as a (hopefully) temporary measure while a more permanent solution is found. The main difference is that Arc (Atomically Reference Counted) is thread-safe and Rc (Reference Counted) isn't.

[lucasfernog]

Windows issue is Tried to wake up a closed EventLoop. I'm investigating.