Provide type hints for internal event emits

[ajbozarth]

Is your feature request related to a problem? Please describe.
Currently the Emitter emits data as an Any object, in our internal emits that object is a dict. In TS that object is dynamically typed, something that's impossible in python. As I detailed in #378 (comment) there are many ways around this issue.

Describe the solution you'd like
To partially mirror the TS implementation I plan to create a dictionary of Types for each internal emit object that a user can then use to set their expected type for a given emit output.

Describe alternatives you've considered
I am yet unsure how I will code the above and am open to ideas. There a few alternative ideas that can work instead or in parallel to the above: enforcing a dict type or BaseModel type on the emit data instead of Any, create a similar typing object to TS and find a way to leverage it without knowing getting the key fro the same def line.

Additional context
This was originally part of the emitter followup work but was never split out into it's own subtask

[ajbozarth]

This is absolutely not a priority for the upcoming release. I opened it so I don't forget to come back to it later.

[ajbozarth]

So I decided to take a stab at this and went down a hole for a while trying to type the emitter event data and ended up with main...ajbozarth:beeai-framework:event_type which is currently broken.
@Tomas2D if you want to take a quick look at that diff and see if that kind of an implementation is something we want to pursue, depending on interest I can work on it further.

After coming up short on that I wrote up a doc on our API as it is now (including some currently missing emits in runner) and with the new emits that will be added in #416
@jenna-winkler you can find that doc here on one of my branches, I can open a PR with it depending on how you'd like to integrate that content.

[jenna-winkler]

@ajbozarth nice! 🙌 Please open a PR draft and I can add to it

[ajbozarth]

Summary of todays discussion:

• feat: POC typed emitter data #432 has been opened with my initial POC for typed event data, @Tomas2D will review and if we decided to move forward with it I will work on cleaning it up and getting it fully functional
• If we decide to not go forward with feat: POC typed emitter data #432 then we will document the current API as in refactor: update user-facing event data to all be dict and add docs #431, in addition we will consider updating any public-facing events to all return dict objects so a more consistent experience.
• The discussion on which direction to take should be decided by Monday's call to leave time for the above followup tasks

[ajbozarth]

I've updated #432 with the latest status, we'll be pushing forward with #431 for this release but leave #432 open to come back to