Rework event keywords to be less finicky

[xylix]

High level goals:

• [ ] Event listeners should not "hang around" after the event that was meant to handled happens by default
• [ ] Figure out (go manually through them and triage the bugs behind) what causes most user issues with Promise To Upload File and Promise to Wait For Download, and tackle that (either through documentation or through improvements with the keywords)

[xylix]

Old TODO history moved here:

• It should be clear if an event handling keyword requires a promise wrapper
• We should try to enable a natural user pattern of first doing things, then event happens, then you get the result

Click  \#fileupload
Select Files To Upload

Should be possible

TODO:

• [x] Remame Handle Alert to Handle Future Dialog(s)

  • Handle Future Dialogs action text action: <accept | dismiss | None > if None it is turned off

• [ ] Handle Future Upload

• Use event "cache" to support following

  • [ ] Handle Current Dialog action text
  • [x] Select Files to Upload / Handle Current Upload
  • [ ] Wait For Download started waits for a new Download and returns a handle to this download
  • [ ] Wait For Download finished download_handle=NEW < NEW | ALL | guid > this returns a path or a tuple of paths
  • Get Dialog
    • [ ] Get Dialog Text == please click yes!
    • [ ] Get Dialog Type

Implementation using "event caches" for last download event, last dialog etc. was tried in https://github.com/MarketSquare/robotframework-browser/pull/339 without success. Some new solutions could be tried for at least the global state handling, like an application global KV storage with UUID -> last event of type X mappings

[Snooz82]

no one implemented and no one wanted it