[docs] Clarify asyncness of events

[betamos]

The events guide contains examples showing how to emit events to the backend:

// emits the `click` event with the object payload
emit('click', {
  theMessage: 'Tauri is awesome!'
})

Note that emit returns an empty promise, which is discarded here and suggests an incorrect usage of the API. I suggest that the docs should answer at least these questions:

• Can these promises be safely discarded without introducing leaks or race conditions with other events or commands? If so...
• In what circumstances should one await the promise?
• Are events received in the same order as they are sent, independent of whether the promise is awaited?

My use case:
I will use pure events as the primary comms channel for my app, which can mean thousands of events in both directions. I need strict ordering guarantees and to prevent leaks. I don't need confirmation of delivery (if so, I would have used commands/invoke). All else equal, I'd prefer not to use promises - since it'd require me to asyncify parts of my application without any inherent concurrency.

[simonhyll]

To my knowledge the emit promise can be safely ignored IF you don't care for confirmation on its success. If the Promise throws an error then the IPC has failed somehow, if it's just an empty response it means it succeeded. Per design anything that interacts with Tauri involves IPC, so Promises aren't just a matter of enabling async operations that don't block the main thread, it's also a means of verifying operations were carried out successfully.

I'll try to squeeze this sort of information into the 2.0 docs somewhere, there have been a lot of questions after all regarding why promises are necessary and requests for a sync version of the api, things like that.