Closes #169

Implements a GameplayEventBroadcaster which is responsible for transmitting events to clients. This allows for third party utilities or DIY setups to perhaps do fancy things using the events.

The broadcaster uses a NamedPipeServerStream to transmit data. There is no reason as to why I chose that, it just worked. May consider using something else if deemed necessary.

Clients can use a NamedPipeClientStream to connect to the mentioned server, and receive events. A basic client implementation can be found here. (Perhaps a compatible pipe implementation may work as well?)

All event broadcasts are 8 bits long, the 5 largest bits used to determine event type, and the smallest 3 for auxiliary information like Lane numbers. The reference data structure for broadcasts can be found here.

Possible considerations

• A different method may need to be considered if named pipes are inadequate, for platform/language compatibility or any other reasons.
• I believe the 8 bits we use is sufficient to transmit all of the events that I could think of, most of which are to program ring button behavior. This may need to be expanded based on needs.
• Currently, only one client can receive events. The first one to connect will get all the events. Will we even need more than one client running locally on any given machine?
• CI on ubuntu seems to fail spectacularly, as if pipes aren't functional. Unsure if it is a problem with dotnet, GitHub Actions, or something I didn't consider. Will get a ubuntu setup running this week to test. It was a problem with me not considering Linux specific exceptions due to the use of sockets