Proposed changes to #9 Support parsing of SSE events

[bflyblue]

Just tracking small changes to #9 like formatting here :)

[bflyblue]

@micahhahn How do you typically use the eventType and eventId? I'm looking at issue #4 and this in particular:

If we write our own parser of SSE, should we move one step furthur to create our own ServerEvent data type that takes a type variable representing the event data? Like how servant deals with request/response body, the user of this library won't need to call marshal/unmarshal function.

Since we are making a breaking change to ServerEvent already, would it make more sense to have it parameterised over the type for eventData? eg.

data ServerEvent a = ServerEvent
  { eventType :: !(Maybe Text)
  , eventId :: !(Maybe Text)
  , eventData :: !a
  }

[micahhahn]

Hey! So the LLM server (Anthropic) we are trying to talk to doesn't use the eventId field and has the "type" of the event in present in both the eventType and eventData - backwards compatibility I think from before they set the eventType field.

FWIW, I'm not quite so convinced any more that the fields of ServerEvent should be Text. For one, the version of aeson we use doesn't support parsing from Text 🤦‍♂️. Also, I've realized that my fears that using a ByteString parser to look for '\r' and '\n' were unfounded as any ASCII characters are guaranteed to be unique in a UTF-8 stream of bytes.

All that to say, if you prefer to switch the ServerEvent back to ByteString and make this a non-breaking change I would be OK with that as well.