refactor: enhance event system rust apis

[amrbashir]

What kind of change does this PR introduce?

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

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

The goal of this PR is to remove the trigger term from the APIs which I don't see very often and would prefer to ditch and stick to listen and emit only.

Changed emit to emit events to JS and Rust side which should be the default IMO but should we provide another set of APIs to target either JS or Rust?

[amrbashir]

So I keep going back and forth between two decisions about one final piece of this PR which is Manager::listen_global and Manager::once_global:

1. Keep them as is, to know that it is global
2. Renamed them to Manager::listen and Manager::once, and when used from App/AppHandle it will be global and when used from Window it will be specific to this window.

Also since I have changed emit to emit events to JS and Rust side and not only JS side, which should be the default IMO but should we provide another set of APIs to target either JS or Rust?

[lucasfernog]

I think @chippers might help you decide since he designed most of these APIs :)

[amrbashir]

I think this PR is ready to go, I have decided to keep Window::listen to be specific to window and Manager::listen_global to be global. I am not the biggest fan of having _global prefix but good enough for now.