refactor: Split codebase into client-server architecture

[vyfor]

Description

This PR introduces a client-server architecture for the plugin, replacing the dynamic library loaded via FFI. The primary goal is to improve flexibility and maintainability. The server can potentially run independently of Neovim, allowing multiple Lua clients to connect to the same underlying server. Communication between the client and server will use named pipes on Windows and Unix domain sockets on Unix-like systems, with MessagePack as the communication format. The server could also stay active for a brief moment after all clients have disconnected to handle Discord's rate limits more effectively.

Considerations

• Keep dependency count to zero.
• Do the new changes maintain compatibility with Neovim 0.5+?
• Will this improve/degrade performance on the Lua side? The impact is likely to be positive, as we can leverage libuv's async API.

Todos

• Complete the Rust backend.
  • Refactor the existing API into a cleaner and more modular architecture.
  • Implement the IPC server:
    • on Unix*.
    • on Windows.
    • Use a lockfile to ensure only a single server instance is running.
  • Handle multiple sessions with unique configurations.
  • Design and implement a modular event system transported via message channels:
    • Define the message struct, and local, client, and server event structs.
    • Implement a message handling.
    • Handle events.
  • JSON implementation:
    • Serialization.
    • Deserialization.
  • MessagePack implementation:
    • Serialization.
    • Deserialization.
  • Implement proper multithreading and synchronization.
  • CLI.
• Connect the Lua client to the backend:
  • Refactor and Modularize Lua Code.
  • Implement IPC client.
  • Create event handling system.
  • Support custom hooks and function values in the plugin configuration.
  • Move several Rust's functionality into the Lua side:
    • Workspace detection based on VCS markers.
    • Git repository detection based on git's config file.
    • Mappings for languages and other components.
    • Building activities.
  • Adopt an event-driven architecture.
  • Add user commands.
  • Add mappings for docs and dashboard. (icon request: vim docs/help #129, Add support for "start screen" plugins #89)
  • Server executable:
    • Automatically spawn the server if pipe is not found.
    • Automatically move the executable to Neovim's data dir. Stop and restart the process if needed.
• Document the codebase for future contributors.
• Update Readme.
• Write a migration guide for existing users.
• Write a configuration guide.
• Better error handling #112
• Move file icons to a separate repository #116
• Multiple neovim support #120

*Pipe creation and connection haven’t been tested on Unix systems yet. If anyone can test this, it would be a big help!

[vyfor]

nvim does expose its msgpack encoder through vim.mpack. depending on its implementation complexity, i might consider rewriting the backend to use that instead of JSON as it's much more performant. we'll keep the JSON parts for communication with Discord.

[vyfor]

This isn’t directly related to the plugin itself, but since we support oil.nvim by default, I wanted to bring it up as it might cause issues for oil.nvim users. The problem is that the current buffer gets set to an invalid/incomplete path, missing a colon after the drive letter, which interferes with workspace detection. I believe this also affects the previous version of cord.nvim. While we could work around this with string manipulation to add the colon, it’s not ideal. It’d be fantastic if this could be addressed in oil.nvim directly. Tracked in stevearc/oil.nvim#531.