allow event listeners to be nested

[chippers]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• New Binding Issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes. Issue #___
• No

The PR fulfills these requirements:

• When resolving a specific issue, it's referenced in the PR's title (e.g. fix: #xxx[,#xxx], where "xxx" is the issue number)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
This builds upon #1446 and #1506. The core issue is that event handler closures are ran inside of Listeners::trigger while it has a lock on the handlers. There are 4 exposed event functions that Mutex::lock() the listeners: Listeners::listen, Listeners::once, Listeners::unlisten, and Listeners::trigger. If any of those 4 are called from inside the event handler closure, then a deadlock will occur because the closure runner (Listeners::trigger) already locked it.

I saw a few non-breaking solutions to this:

1. Clone the handlers inside of Listeners::trigger, after getting them from the lock, and then use their closures.
2. Like fix(event): once deadlock #1446, spawn an async task to wait for the lock later. This downside is that when that will be executed is unknown, and can cause things like Listeners::once being able to be called multiple times if called soon enough.
3. (this PR) Use non-blocking Mutex::try_lock() locking inside those mentioned 4 functions, adding to a pending queue if the handlers are currently already locked. Listeners::trigger, has been modified so that if any event handler closure was executed, all pending events will be flushed in the order they were added.

A side-effect of the chosen solution is that nested event calls technically don't happen during the closure - but after it. This is something we should document so that users expect this behavior. In all cases I can think of right now, this side-effect doesn't matter much since the execution order of different closures was already non-deterministic (another thing we should document).

use tauri::{Builder, Manager};

fn main() {
  Builder::default()
    .on_page_load(|window, _| {
      let foo = window.listen("foo".into(), |event| {
        println!("foo: {:?}", event);
      });

      let window_ = window.clone();
      window.listen("bar".into(), move |event| {
        window_.unlisten(foo);
        println!("bar: {:?}", event);
      });

      window.trigger("foo".into(), None);
      window.trigger("bar".into(), None);
      window.trigger("foo".into(), None);
    })
    .run(tauri::generate_context!())
    .expect("error while running tauri application");
}

fix/nested-events:

foo: Event { id: EventHandler(d9bc19f3-aea5-46bf-ad7f-5d7ea36a384f), data: None }
bar: Event { id: EventHandler(b762e118-e50c-4aa6-9b11-35c060be9b70), data: None }

dev:

foo: Event { id: EventHandler(8ba87934-916a-437e-bb2f-fef106ade9e7), data: None }

[deadlocks]