feat: Add make targets to build snap from worktree

[MaikRe]

Adds two new make targets and additional supporting functionality to make the UI and docs build works

make snap-work-tree functions essentially identical to make snap-tree expect that it cannot fetch the UI commit hash so it must be build locally.
make snap-work-tree-sync functions essentially identical to make snap-tree-sync.

Testing procedure:

cd /path/to/your/maas/repo
git worktree add ../new-worktree -b branch_name maik/snap-worktree # Specifically checkout this branch as obviously need the make targets
cd ../new-worktree
# To test from a truly clean environment
make snap-clean
make snap-tree-clean

make snap-work-tree

The work tree can then be mounted into an LXD container etc and updated with make snap-work-tree-sync

[maas-lander]

Check where you would like a Mattermost message to be sent to when CI completes and this PR is merged

• Direct message
• ~maas

[AloizioMacedo]

You don't need to go to the repo root, git rev-parse --is-inside-work-tree should figure things out correctly (this would only be a potential problem in something like the maasui dir, which is a submodule).

So you can just use cwd=Path(__file__).resolve().parents[0]. Since we are already cleaning up the awkward check, this also gets a little more resilience since we don't need to assume we are inside another dir. Theoretically there should be no problem in building the docs with the docs folder as root, in principle (e.g., if I mv everything of the docs folder inside the root of a docker container things could just work) and the current version would panic with a IndexError in that case. (Practically, we still use references to the package due to the API/CLI reference, but this will most likely change in the future, and there is no need to make extraneous assumptions where not necessary)

[AloizioMacedo]

With the changes proposed in place, those could be actually replacements of snap-tree and snap-tree-sync, right? They would work by having a standard git clone'd repo as well.

Maybe you are just trying to prevent overwriting the usual way due to potential unforeseen issues. In that case, maybe opening a new PR later with just the replacement itself? The point being that this is a kind of duplication.

[MaikRe]

Maybe you are just trying to prevent overwriting the usual way due to potential unforeseen issues. In that case, maybe opening a new PR later with just the replacement itself? The point being that this is a kind of duplication.

Yes that is my primary issue.
But for now I think I will table this until the monorepo #259 discussion is done as that might simplify some things as well.