Separate the events API for plugins

[emoon]

Right now plugins can request data from the backend and then get back an event of the request. The idea with the current design is that anyone can listen to any events which is useful in some cases but mostly actually not. This design leads to some problems:

• When a plugin makes a request it doesn't get a confirmation that the request has failed or not. Say requesting memory that wasn't able to be read.
• As requests are global that means there is hard to tell the difference between between requests of the same time (say that two memory views requests different chunks of data)

Suggestion is to:

• Still keep events. Events would be things like set_exception_location, step, break and requests would be more of the type request_memory, request_disassembly, etc
• Remove the "action" variable being sent to the plugins, move that over to events instead.
• Requests should be more RPC like with getting a replay back whatever the request completed or not.

[emoon]

I suggest an temporary approach for now as this will become an issue otherwise before 0.1

1. When doing begin_event a handle will be returned. (u64) in some cases this handle makes sense to use and some it doesn't
2. When someone replies to an event (get_memory/set_memory) set memory needs to supply back the id again to so that the requester can check for the correct id. Id can retrieved as get_u64("request_id")

This is by far not the best way to do it but I think it will work until we have something more robust in place.

cc @SlNPacifist