Feature/Refacto: Conflate all VCSes under an umbrella vcs module

[poliorcetics]

Feature Request

Context: original idea came from #5772 (comment)

Is your feature request related to a problem? Please describe.

A few months ago I started using jj a lot. jj as a mode where its .jj/ folder is colocated with the .git/ folder. Using #5814 I then end up with both git and jj in my prompt when I only want the later.

I suspect this can also happen for people in very specific setups where they use hg for one mirror and git for another but I don't know of any real world case for that. If you have one I'm interested!

Describe the solution you'd like

The solution I'm thinking of is the following:

[vcs] # New module

# VCS detection is attempted in this order.
# The first one returning a successful response is the one that will be used in the final output
#
# They should be in the default order from: "most likely to be used" to "least likely"
# so that most people don't pay the cost of tools they don't use
order = [
    "git",
    "hg",
    "jj",
    "pijul",
]

# The format to use for each VCS
format.git = "$git_state$git_branch$git_status"
format.hg = "$hg_branch"

[vcs.modules.git_branch]
# Same config options as the current toplevel `git_branch`

[vcs.modules.git_status]
# Again

Top level VCS modules would disappear and only $vcs would be available instead of $git_state$git_branch for example.

Advantages

• It would be possible for the vcs module to detect that for example both $git_state and $git_branch are used and so do one request to get all the information instead of two. For most repos it's not a big deal but it could help the git_status module be less costly on bigger ones maybe.
  • For jj for example, where using a library is not possible, it would be very helpful to do that.
• It would avoid unnecessary costs: if a user activates both hg_branch and git_branch currently, starship has to check for both. With vcs, once it finds git (with the order above), it stops, avoiding paying the cost for hg

Disadvantages

• It forces using only one VCS at a time in the status line: I can't think of a situation where I want two VCSes in my statusline. In the jj case, if I want git infos, I do git commands since it's very rare: paying the cost on every prompt seems strange
• It's a breaking change
  • That's easily solved by simply saying vcs uses the config from the top level modules (git_branch instead of vcs.modules.git_branch) instead of having its own subconfigs. vcswould then end up with onlyorderandformat.` as members.
  • I don't like that solution as much because it forces us to support both use case in starship which would be annoying (caches would have to be shared to avoid duplicate costs, different VCSes would have to be tested despite $vcs trying to fix that, ...), especially considering it opens the option of $vcs$git_branch in the prompt config. We could disallow having "top level free VCSes modules" in the same prompt as $vcs but I think that would be a first in starship and not a good experience for a user trying to build their own prompt.

Describe alternatives you've considered

There is #818. The problem with that is that we don't have a Repo type for all VCSes nor even a Rust lib to use. We could "fudge" it by having our own Repo type for those missing ones but that's probably not a repo anymore but just a cache of relevant infos and would be confusing to document.

This issue also mentions having $vcs_branch instead of different $<vcs>_branch for each VCS: that's wrong because it implies all VCSes will have a concept of branches that map to each other but that's not the case at all: git, hg, pijul, jj and fossil are the VCSes I'm thinking of and they don't all have the concept of branches, sometimes it's not under that name (e.g. "channels" in pijul) and while branches are one of the most portable concept, lots of others are not: change_id vs commit_id in jj, topics in hg, tags from git

Working on it

I'm fully willing to do the work on all of this! This is an issue is to confirm maintainers are interested and hash out issues before I spend hours working on it :)