extract cache logic out of gm itself

[amtoine]

as explained in #24 (comment), i encountered a cache bug when working on #39 => because the cache path can now be fully set by the user with $env.GIT_REPOS_CACHE, it does not have the .nuon extension in general and thus we cannot assume open $env.GIT_REPOS_CACHE to open the file as NUON data...

description

in order to allow testing more of the internals of the gm commands, i propose in this PR to move the cache logic as much as possible from gm itself to a new internal fs/cache.nu module.

Important
this might sounds like clean code, e.g. where you put all the code in nested oneliners...
i would argue it's not the goal of this PR and the fact that the resulting commands are quite small is simply because they are doing quite simple stuff!
the goal here is to move the internal logic out of the public gm which exposes the main API to allow testing as much as possible without require to gm clone actual repositories or gm remove in an interactive manner 😋

changelog

• move get-repo-store-cache-path and check-cache-file to a new fs/cache.nu module
• move most of the cache logic to commands in fs/cache.nu
• adds tests for the cache functionalities

tests

a new cache-manipulation test in tests/mod.nu.

[amtoine]

@melMass
do you think this should address the last task of #24 and thus close the issue?
or do you think we need real integration / end-to-end tests where the CI runs gm clone, gm remove, ..., for real?

[amtoine]

Note

• d44e4e0 makes the output of failed tests easier to read
• 99af26d and 67350aa sanitize PWD and paths added to / removed from cache to fix the tests on Windows

[melMass]

@melMass do you think this should address the last task of #24 and thus close the issue? or do you think we need real integration / end-to-end tests where the CI runs gm clone, gm remove, ..., for real?

What is the link between the two? Sorry I don't see it.