This can be useful for those who seek extra information, and while it's
dominating refresh times.

It calls `list_virtual_branches()` which kind of has the effect of a status call.

There we don't necessarily need every last bit of optimization like
one would want in release profiles, but build performance is of the essence
for developer productivity.

The worktree diff is essentially a 'git status' with a given tree,
and that can be expressed with a diff of the workdir, the index and a tree.

This comes at the expense of not being able to control which file sizes are diffed.

````
GITBUTLER_PERFORMANCE_LOG=1 LOG_LEVEL=debug pnpm tauri dev
````

Additionally, some noise was removed by turning a warning into
a trace.

…nches.

That way, the head is static which allows to re-use the worktree status across
multiple related calls.

Also, add a way to quickly get the `head_commit()` from a `git2::Repository`.

Note that this may cause breakage in the app, as now it will see the actual
head, not a computed one, but that should also help us to find places that
didn't properly update their state.

Also make sure that important `gix` crates are always compiled
with optimization for proper performance.

This is particularly useful when optimizing performance as not
everything has to be done in release mode.

However, it also causes CI to be slower as it compiles some
dependencies longer.

The problem realy is that `tauri dev` doesn't support custom profiles,
so there is only `dev` and `release`.

It's used for emission of changed files, but also for listing
branch information.

Make sure we only run the worktree-status once to save time.

This also unifies the acquisition of the `HEAD^{commit}`,
which one day will be a natural feature once `gix::Repository`
is used.

- move `gix` repository extension to where it belongs more naturally.
- make sure that `get_wd_tree()` is named more closely to what it really
  does, and use it in more places.

This was lost previously when switching it over to a read-only
implementation.
Implementing it with an ignore list will take time, 400ms in the GitLab
repository, but it's not slower than it was before and it is always
preferred to not dump objects into the ODB unnecessarily.

That way, the application will not run into unexpected cases.