Initial creation of paket.config produces malformed file

Description

Running paket config add-credentials with no existing paket.config file produces a malformed paket.config file (encoding in XML header does not match actual file encoding) which subsequently cannot be read in by paket. Seems to be related to #1954

Repro steps

1. Delete (or otherwise remove) your paket.config file
2. Use paket config add-credentials <somedomain> to add to the credential store
3. Run some paket command that hits the <somedomain> NuGet server (e.g. paket update)

Environment: Windows 10 Pro, 64-bit, paket 3.26.3 (also seen in 3.23.2).

Expected behavior

Command run in step 2 creates valid paket.config file; command run in step 3 uses the credentials entered in step 2.

Actual behavior

Command run in step 2 writes out a UTF-8 encoded paket.config file, but the <?xml ... ?> declaration at the top specifies it to be UTF-16. Command in step 3 is unable to read the file and exits with an error.

Known workarounds

Edit the paket.config file after creation so that the <?xml ... ?> declaration specifies UTF-8, or have an existing valid paket.config file.

[jdpage]

Doesn’t System.Xml.XmlWriter handle formatting and XML declarations and formatting and stuff properly for you? Going through that is probably safer than just assuming the file encoding.

If nobody minds I can author a pull request that uses that API instead, which should head off any possible future encoding-related problems.

[jdpage]

Finally got a chance to come back around and do the System.Xml.XmlWriter version.