It will hold the current credentials helper implementation and might
contain more one day.

Primarily meant to interface with `git-sec` when needed, even though
currently it deals with git directly.

Otherwise we wouldn't know if the dependency resolution breaks.

It's shared across crates.

…d `identity::UserId` (#386)

As the fewest consumers will be able to deal with multiple identities,
remove the enumeration approach in favor of individual type which deal
with one specific way of identifying a user.

For posterity, using the windows API is absolutely terrible and
I hope I don't have to do it again anytime soon.

More importantly, I hope that it works nonetheless.

…386)

Is it desirable have permissions tagged like this?
These would typically show up in options, and I have a feeling it makes
them more descriptive. That's all really.

…ory (#386)

There is also the notion of a 'main' worktree, the one we usually
get when cloning non-bare. And we can currently instantiate a Repository
from a worktree that isn't the main one.

Hence, when opening a repository permissions are already derived
from Trust, and next up is to figure out how to get there so that
open/discover can decide what to do while being configurable in full.

That way it's possible to ignore repositories which effectively
aren't owned by the current user, or to not ignore them (default)
but assign tigher permissions to the repository.

It should be possible to control which configuration files are loaded
and contribute to the overall configuration. This goes along with
at some point allowing to obtain only values which are from trusted
configuration files, based on the trust specification passed when
loading the configuration.