This PR is based on #6 and #7

Hi! I'm opening this PR as a draft so I can get some early feedback; I've started taking the inverse websocket in a different direction than the spot/linear implementations and wanted to sync with you on this before it went too far off in the weeds. I'm not sure if some of these changes uphold the goals or direction you want to take this project, so I thought I'd ask!

I started consuming the inverse websocket library from an application I'm writing and these changes were helpful in keeping the consuming code readable and fun:

• exporting the type of an enum variant (I'm not sure if these words make sense, hopefully I'm close) This allows me to write a function expecting data from a particular response message

    pub fn initialize_from_snapshot(&mut self, snapshot_message: &OrderBookL2SnapshotMessage) {
        for rung in snapshot_message.data.iter() {
            self.insert_bybit_rung(rung);
        }
    }
  

  Well... now that I say this, I should probably just pass &Vec<OrderBookItem> and &OrderBookDelta (both already exported). Maybe this case is no longer as important to support, but it did bring the next point to my attention

• create a distinction between the response or message and the contained data For example, we had

  pub struct BaseResponse<'a, D> {
      pub topic: &'a str,
      pub data: D,
  }
  
  pub enum PublicResponse<'a> {
      #[serde(borrow)]
      Trade(BaseResponse<Vec<Trade>>),
      // ...
  }
  

  This naturally had me thinking of the entire BaseResponse<Vec<Trade>> as a Trade (the enum variant) which caused a bit of a jerk when I accessed the data which was a ... Trade. It seemed more natural to refer to the unedited response as a TradeMessage which contains a Vec<Trade>. This rename causes the callback to be a little more verbose but seems to increase clarity everywhere else.

• deserializing some raw websocket values into a different type This is the most questionable change, because if the project goal is to be as fast as possible, this may perform more work than is necessary in all cases. Also, there can be some precision issues when changing a string-of-a-number into a f64, but I'm not sure of any other, superior way of dealing with floats in Rust so I figure this conversion is sort of inevitable.

  Rather than handling these conversions on the client's side, I moved this logic into the deserializer using a crate called serde-aux. I've started to deserialize Side into an enum as well, which makes the client's logic cleaner and lets me lean on the type system more.

• adding tests, currently only of deserialization logic I'm always a bit confused reading the serde documentation, so I wrote tests to prove the deserialization would work as I expected it to. I'm not sure yet how to test every part of this implementation but I'm excited to keep pushing for higher test coverage

That's about it, so I guess my goals for these diffs are

• leverage the type system to increase confidence about correctness and improve developer experience through "implementation by cases"
• provide a great developer experience by presenting information from Bybit's API in a way that minimizes wtfs-per-minute (Bybit leaves a lot of room for improvement here)

Thanks in advance!

Following a conversation here, this commit tries to document project goals. We can use these goals as a compass to decide which changes are in scope and which are out of scope.

Currently, this project is meant to be a lightweight layer for interacting with Bybit's WebSocket API. Performance is king, and this means many conveniences may have to be built into separate packages that build upon this package.

This should make it easier to bring this project into a "complete" state.