feat(client): frontend prototype using egui

[AshesOfEther]

Note: I've largely abandoned this PR. Anyone may feel free to take it over and continue it if they want. See this comment for details.

---

Description

This pull request is for a custom frontend prototype using egui. While Loki itself focuses on performance, this prototype instead focuses on rapid development. It is currently still in development, and not ready to be merged.

Motivation

The current plan is to make a client using our custom UI framework, lokui. This, however, means that before we can even get started on developing the user interface of our client, lokui needs to be ready, which will likely take a while.

Having a frontend is useful for development, because it makes it easier to test other parts of Loki, such as the backend and the API/protocol. Therefore, the earlier we have one, the faster these other areas can get started.

Additionally, parts of this prototype may end up being reusable in the final client. This means that once lokui is ready, it will take less time to reach a fully functional client.

Overall, this will likely bring down development time.

Alternatives

1. Create a TUI frontend instead. This would not work well with things like images.

2. Use a different GUI framework. Other frameworks did not get particularly much consideration. I like egui for this due to the simplicity of its immediate mode API.

3. Don't create a prototype. The benefits of a prototype have been outlined above.

[AshesOfEther]

So, at this point the prototype looks and acts like a very minimal chat app. You can create guilds, and send messages. Additionally, it can keep track of users it knows about in order to display info about them. This should be a good start, though it's definitely not enough. It is at the point where I would like to start hearing about what should be implemented, and where it might be possible to hook it up to a basic client library.

I believe I read that if the client is to have an async runtime, then that should be in another thread because otherwise it would block the main thread. That could mean wrapping the state in an Arc<Mutex> so that both threads can write to it. This might result in the UI thread having to wait on the async thread to write stuff in case there are updates to the state, but the only alternative I can think of is sending messages to the UI thread, meaning that UI can't be drawn until state has been updated anyway.

In any case, I'm opening this up to reviews in case anyone has any comments, but don't merge it yet.

[AshesOfEther]

After further consideration, it needs to be possible for the async thread to notify the UI thread of things directly, meaning that a message channel is needed either way.

[AshesOfEther]

I probably won't be adding anything more to this. Anyone else who wants to help out and is looking for something to do can take over this if they want. I'll be happy to help out if anything is needed. The codebase is a bit underdocumented 😅, so yell at me and I'll probably add some docs (I'm a big believer in the idea that app codebases should be documented just the same that libraries should).

At the moment, the main ongoing task is creating a separate thread with an async runtime, and creating a system to share state and send messages between these. Then, the async thread will be able to host what will become the client library.

I largely consider this prototype exempt from the philosophy of minimizing dependencies, since the goal is development speed, not quality or performance, within a reasonable extent of course. I'll let whoever takes this over decide on what they wanna do with that.