refactor!: Decouple breakwater-parser to make it easier to integrate elsewhere

[bits0rcerer]

This pull request hides breakwaters framebuffer implementation behind a trait and decouples breakwater-parser from breakwater-core (in fact reverses the dependency).
This allows other project to use the breakwater magic but implement their own framebuffer.

These change do not introduce dynamic dispatch so runtime performance should™ not be affected.

[sbernauer]

Hi @bits0rcerer nice to hear from you and thanks for the proposal! Looking forward to a fancy new framebuffer ;)

I think it makes total sense to put Framebuffer behind a trait. However I noticed a few things:

• tests and benches fail to compile, clippy and rustfmt are failing
• struct Framebuffer still implements functions which I would like to see on the Trait (fn as_bytes(&self) -> &[u8]; to be precise)
• Once we added the needed as_bytes function the VNC and ffmpeg sinks can use the Framebuffer trait instead of one specific implementation , so that you can use your own for that. All you need to provide is the as_bytes fn, which I hope you can do.
• Looking at what remains in breakwater-core I'm wondering if we need it at all. I think I would be in favor of removing it, what would be your opinion?

I did some formatting changes in ebfa821 and made a proposal how the proposed changes above would look in 408aee7.

It would be awesome if you could have a look and provide feedback what you think about that.
The second commit also fixes compilation errors in tests and benches.

[sbernauer]

Small update: I merged #34 first, as I think this way we will get less merge conflicts.
However, I did address all conflicts in https://github.com/sbernauer/breakwater/tree/decouple-parser-review, so this should not put additional work on your end. Hope that works for you!

[sbernauer]

I merged #37 containing your commits, so that I can use the new trait for a feature I'm working on (native windows in addition to VNC). Happy about feedback if the trait works for you!