EventManager API update and Button API update

[finger563]

Description

• Updated Event Manager API to work with std::vector<uint8_t> instead of std::string for better interoperability (fewer copies) with serialization library.
• Fixed bug in EventManager subscriber callback which was only dequing one element of data each time it woke from notify, even though there could be multiple data elements in the queue.
• Refactored tuple typedef and use into a struct for cleaner code.
• Added dequeue mutex protection around dequeue insertion for publish
• Removed event manager and serialization from button component and class, in favor of simply calling a callback function
• Updated button example to use the new callback API but to include event manager example for button subscription / data distribution example since many systems may have multiple comonents that are interested in button presses. Uses new event manager API as well

Motivation and Context

Fixes a bug in the EventManager class which I found when testing the Button class where if multiple events got published/queued before the subscriber could dequeue and process them, then the subscriber would always be one event off in time / would not receive the last event.

Updates the EventManager class to use std::vector<uint8_t> for data for more direct interoperability with the serialization / alpaca library which can only serialize into vectors or similar containers (not std::string). Since the EventManager is designed to be used with custom data types (structs and other containers), this seems like a logical choice. The example still shows an example of passing std::strings through events though in case people want to do that.

Finally, updates the Button implementation and API to remove the dependency on the EventManager and serialization components since that seemed to be out of the scope of that class explicitly. Now the Button takes a callback function that it calls with the associated event structure instead. To showcase the use of this with the event manager as it was originally intended (to be able to easily distribute events throughout the system) the event manager / serialization code was moved in to the button example.

How has this been tested?

• Building and running the event_manager example
• Building and running the button example

Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):

EventManager Example

Button Example

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Hardware (schematic, board, system design) change
• Software change

Checklist:

• My change requires a change to the documentation.
• I have added / updated the documentation related to this change via either README or WIKI

Software

• I have added tests to cover my changes.
• I have updated the .github/workflows/build.yml file to add my new test to the automated cloud build github action.
• All new and existing tests passed.
• My code follows the code style of this project.