A more plugin-friendly design

Since atuin 18.13.0 the scope of the project has ballooned quite a bit that it is becoming quite a bit harder to review what is going on, and how to package the project in downstream. Many initial users came to the project just for a local command history manager, and I would like to have a way to package for this audience without exposing them to the daemon workflow, any egress connections, AI features, etc., just the bare minimum of the interface. The users can then opt-in to each feature by installing the relevant sub-packages.

Right now this is not possible. The user could seemingly opt-in at build-time using the features, but that is not a friendly approach for the downstream packaging.

The minimum split that we would like to offer is:

• atuin: the core functionality and interface
• atuin-local/remote: to include or not the syncing to a remote server
• atuin-daemon: to include the systemd service file
• atuin-server: (already available)
• atuin-ai: because many users will be vocal towards us about forcing this on them
• atuin-hex: because this would need a different variant of the files packaged for the normal run and it fundamentally changes the terminal