Fixed path for user-only installation of GCM for Windows.
Seems #551 forgot to update this path.

version: v2.1.2
imagePath: `C:\Users\user`
```
$ git config --global credential.helper "/mnt/c/Users/user/AppData/Local/Programs/Git\ Credential\ Manager/git-credential-manager.exe"
$ git pull
Already up to date.
```

Update the current VERSION placeholder for the git-credential-manager-core
to git-credential-manager rename to 2.0.877 (the version with which this
update was released).

Update the current VERSION placeholder for the
git-credential-manager-core to git-credential-manager rename to 2.0.877
(since that is the version with which this update was released).

Fixes #1318

Ensure that we read helper UI standard output as UTF-8. Helper
applications already write output with a UTF-8 encoding, so we must
ensure we read using the same encoding in the core application or else
non-ASCII characters may be mangled.

Ensure that we read helper UI standard output as UTF-8. Helper
applications already write output with a UTF-8 encoding, so we must
ensure we read using the same encoding in the core application or else
non-ASCII characters may be mangled.

Fixes #1287

GCM by default creates entries in the Windows Credential Manager on
Windows, and prefixes the 'target name' of the entry with "git:".
This 'namespace' prefix is configurable, but is not often changed in
practice outside of tests.

Visual Studio, when adding GitHub accounts (either natively or by the
older GitHub extension for VS), it creates three credential entries:

1. GitHub for Visual Studio - https://github.com
2. git:https://github.com
3. https://github.com

Entry 1 is used by VS for it's own purposes. Entry 2 is created for the
benefit for GCM, so that we are 'primed'. It is unknown what entry 3 is
for at this time.

There is an error in our existing logic for enumerating credentials that
is also matching entry 3 as well as the expected entry 2.

Modify and fix the matching logic to ensure that the namespace prefix
matches, rather than just stripping it and matching (even if it doesn't
exist!).

For GitHub.com we've updated the redirect URI to 127.0.0.1, whilst also
keeping the localhost variant around for backwards compatibility with
older GCM clients.

However, since GHES has not been updated with the new 127.0.0.1
redirect, and older GHES servers will be stuck with the old redirect we
must continue to use the localhost redirect on the client for
non-dotcom targets.

For GitHub.com we've updated the redirect URI to 127.0.0.1, whilst also
keeping the localhost variant around for backwards compatibility with
older GCM clients.

However, since GHES has not been updated with the new 127.0.0.1
redirect, and older GHES servers will be stuck with the old redirect we
must continue to use the localhost redirect on the client for non-dotcom
targets.

Fixes #1329

…redential Manager (#1328)

GCM by default creates entries in the Windows Credential Manager on
Windows, and prefixes the 'target name' of the entry with "git:". This
'namespace' prefix is configurable, but is not often changed in practice
outside of tests.

Visual Studio, when adding GitHub accounts (either natively or by the
older GitHub extension for VS), it creates three credential entries:

1. GitHub for Visual Studio - https://github.com
2. git:https://github.com
3. https://github.com

Entry 1 is used by VS for it's own purposes. Entry 2 is created for the
benefit for GCM, so that we are 'primed'. It is unknown what entry 3 is
for at this time.

There is an error in our existing logic for enumerating credentials that
is also matching entry 3 as well as the expected entry 2.

Modify and fix the matching logic to ensure that the namespace prefix
matches, rather than just stripping it and matching (even if it doesn't
exist!).

Fixes #1325

---

**Bug repro instructions:**

1. Open Visual Studio
2. File > Account Settings
3. Add a GitHub account
4. Open a terminal (inside or outside of VS) and attempt to
clone/fetch/push to or from a private GitHub repository.

At this point a window should appear asking you to select between two
"Personal Access Token" accounts.

After installing [the bits from this PR build (artifacts >
win-x86)](https://github.com/git-ecosystem/git-credential-manager/pull/1328/checks),
attempting step 4 should **no longer** result in a prompt to select
between two "Personal Access Token" accounts.

Before 2.2.0, we only accepted input arguments in the form key=value.
To support the new wwwauth[] argument from Git, we added support for
these multi-value args key[]=value.

In changing from an dictionary of string:string to string:list<string>
we accidentally changed the behaviour of dictionary parsing in the case
that an empty valued argument was provided. For example:

username=\n

Preivously this was returned as an empty string. Post 2.2.0 this became
`null`, causing an error in scenarios were before there was none.

One such scenario is with Windows Integrated Authentication (for example
when connecting to Azure DevOps Server/TFS instances), whereby we return
an empty username and password to Git to signal this auth mode. Git then
returns to us the empty username and password in a `store` call.

Update the handling in `ParseMultiLine` to restore the previous behaviour
for empty-valued arguments being mapped to the empty string.

Before 2.2.0, we only accepted input arguments in the form `key=value`.
To support the new `wwwauth[]` argument from Git, we added support for
these multi-value args `key[]=value`.

In changing from an dictionary of `string:string` to
`string:list<string>` we accidentally changed the behaviour of
dictionary parsing in the case that an empty valued (non-multi) argument
was provided. For example:

```text
username=\n
```

Previously this was returned as an empty string. Post 2.2.0 this became
`null`, causing an error in scenarios were before there was none.

One such scenario is with Windows Integrated Authentication (for example
when connecting to Azure DevOps Server/TFS instances), whereby we return
an empty username and password to Git to signal this auth mode. Git then
returns to us the empty username and password in a `store` call.

Update the handling in `ParseMultiLine` to restore the previous
behaviour for empty-valued arguments being mapped to the empty string.

Fixes #1331

---

**Bug reproduction steps:**

```console
% printf "url=https://example.com\nusername=\npassword=\n\n" | git credential approve
fatal: Missing 'username' input argument
```