Private snap builds

I don't have an answer to this so far, but I'm going to at least leave my findings here before the end of the week.

Looking at logs from the various services involved, the successful case works as follows:

 * git makes an anonymous request
 * turnip-pack-frontend-http makes an anonymous `translatePath` request to Launchpad, is told that it's unauthorized, and thus returns a 401 to git
 * git makes another request, this time with authorization
 * turnip-pack-frontend-http makes a successful `authenticateWithPassword` request to Launchpad, followed by a successful authenticated `translatePath` request

In the unsuccessful case, git makes an anonymous request which gets 401 as above, and then apparently gives up.

So my best guess at this point is that the relevant difference is that your unsuccessful snap recipe uses `build-base: core18`, while your successful one uses `build-base: core20`: that is, perhaps it's a behaviour difference between git 2.17.1 and 2.25.1, or a difference in the version of libcurl that it's linked against. We need to check that guess. It's possible that there's some configuration option we can change to make this work; another more involved option would be to change Launchpad to use some kind of reserved username instead of the empty string in this case.

And just looking at this quickly, I can confirm that `GIT_TRACE_CURL=1 git clone https://:<email address hidden>/<private repository path>` behaves differently on bionic and focal. Setting `http.emptyAuth=true` seems to work around this. I haven't been able to find the relevant code change as yet, though, and it's not clear whether setting a configuration option on the client side would be the best fix here (it's not something you can do in snapcraft.yaml in any case).

OK, it wasn't a git change at all. I've bisected the fix to https://github.com/curl/curl/commit/46e164069d1a5230e4e64cbd2ff46c46cce056bb, in curl 7.62.0; it wasn't even specifically called out as being fixed there, just fixed in passing as part of a larger refactoring. I think that means it's better to use URLs that don't involve such edge cases, so we should change Launchpad to avoid using an empty username here.

Per the attached bug, this is now done.