Rework the way emacs is launched

The commits 15ce6a9e...a5756023 tackle the large task of finding a way to have emacs launch in daemon mode, so it can be used with emacsclient for very fast load times, and opening files in pre-existing windows code -r style, among other things. Because of how hastily it was thrown together, however, it's produced quite a few badnesses along the way.

Ultimately, one of the more annoying bits of this is how I currently handle launching emacs. This is kinda annoying in a couple of facets:

  1. emacs doesn't draw properly in terminal mode since I overrided the terminal-detection stuff in my doom theme to have my theme work better for graphical emacs clients, making small vim-like commandline edits very difficult.
    • A proper terminal UI is being sketched out in issue #32, this issue primarily focuses on the conflict between terminal styling and emacsclient-frame styling.
  2. Using my alis/bash-script/thing to launch emacs with other files feels clunky, because of bugs like #42 (closed), where centaur-tabs completely breaks whenever I open files outside of the current treemacs workspace. This makes the whole "open files quickly by just doing emacs <thefile> to suck up a file into the frame" advantage kinda useless.
    This is partially ammended since I uninstalled treemacs for neotree, as documented in #54 (closed).
    • Even if the emacs did launch with out-of-workspace buffers properly, it'd still likely be a bit clunkey. Ultimately, we really just want the vscode-like behavior that allowed me to just open a directory, and have the directory tree to the left.
  3. Ideally, I'd like to be able to have multiple emacs windows open for each project. The problem is, since they're all interacting w/ the one server, one might change the environment for the other (which isn't super desirable). Things like windows, buffers, etc, stick around when I don't really want them to.
Edited by MyriaCore