Consider creating a new CLI for Makes

[dsalaza4]

This is a follow-up for #985 (comment).

The TUI we currently have:

1. Looks good when running m .
2. Has a good auto completion.
3. Properly lists all available jobs.

What I don't like about it:

1. Has to load all available jobs before actually displaying something: m . takes a few seconds to display the TUI.
2. Does not allow to copy the name of a specific job so I can later do m . <job-name> for simpler use.

I wonder if there is a way of making job discovery faster so Makes does not have to depend on a TUI that only displays information once all jobs within a repo have been found.

I definitely think that having a CLI that:

1. Has job auto completion
2. Loads as fast as possible (Maybe hard when pointing to external repos m github:<repo>?)

Would provide the best experience when it comes to finding the job you want in the simplest and fastest way.

[jpverde]

What if we take this opportunity to build the CLI differently, what if we use Go for it? try to separate necessary builds in different stages. We can also give a fresher look to the TUI, take a look at this one https://github.com/charmbracelet/bubbletea the framework has different components as well, including auto-completion, pagination, tables, usable lists, etc... https://github.com/charmbracelet/bubbles

[dsalaza4]

@jpverde Feel free to do what you consider best 💯 👊🏽 , let's just try to prioritize:

1. Comfort
2. Speed
3. Looks

In that order.

[jpverde]

Lately I've been thinking about this, re-thinking how the CLI should work and how it can extend makes while making it more friendly and comfortable to use. Here's my proposal:

1. First of all, the initial configuration, I know nix is all in for technical users, but we can still be friendly here, a lot of nix-oriented tools provide (or partially give the option) to initialize a project, what I'm trying to say is something like m init, something that can lead me to initialize my project, offering different kind of options to choose while the CLI follows the configuration through the duration of the command, depending on the user needs of course but taking into account the features that the tool offers.

2. The trigger command m . /job Using makes that way can lead its users to think of it as a "let me memorize the command" only use, we can change that by defining the different types of extensions/features we have (builders, linters, extensions, etc...) I know it sounds a bit complex but we can think of it as "hey, we can provide builders with different languages, show languages as options" something like m build ... where we offer different kinds of builders that we support (nodeJs, Python, etc...).

3. The TUI right now can turn confusing when you have an absurd amount of jobs available, maybe getting rid of it is the best, or if we can categorize the different tools that makes can offer to a project it becomes easier to handle, you want to build something? use m build and we will only list builders, you want to lint something? use m lint and we will only list linters, and something more complex, make it possible to mark different extensions that start a single project m start (like we do with our platform, with DB, front, back, and storage jobs) I know right now we make that possible by using mprocs but makes can do that too.

4. How users can create extensions or those main.nix files across a project, we can offer something like m create or m extend, following the process and creating basic configurations that can just run a project without much effort, we have a lot of examples of how can a user create extensions, we could use those examples for this.

Maybe this is a bit too much and it could be split into different issues, we can define the priority later, but I think it is a correct path to make the product a lot more usable by targeting a lot more users.

[dsalaza4]

Fuzzy matching via fzf looks very good too: https://github.com/junegunn/fzf