Support remote URLs and "github://", "file://" schemes to fetch recipient public keys

[aerth]

This PR supersedes #43 and #64, adding support for github://, file:// and URL schemes (https://) for the -r (RECIPIENT) flag

Closes #84

Example usage:

echo "hello" | age -r github://aerth -o /tmp/encrypted.txt
echo "hello" | age -r https://github.com/aerth.keys -o /tmp/encrypted.txt2
echo "hello" | age -r file://$HOME/.ssh/id_ed25519.pub -o /tmp/encrypted.txt3
echo "hello" | age -r "$(cat $HOME/.ssh/id_ed25519.pub)" -o /tmp/encrypted.txt4

Thank you @paulc for laying the framework for the github:// scheme

[aerth]

worth noting that this introduces networking and uses default net/http client, direct connection (no proxy, system resolver)

someone could later add proxy support via environmental variable or flag

[nxg]

A problem here is that the URI prefix will surely frustrate tab-completion. That is, I can type age -r ~/.ssh/id_r^I and have the recipient filename complete, but I can't type age -r file://~/.ssh/id_r^I and expect it to complete. I can do age -r file://$HOME/.ssh/i^I and it completes (somewhat to my surprise; this works in bash, but not in eg zsh), but that's more typing.

It's a minor usability issue, certainly, but it's enough of an issue that it makes me feel as if I'm missing something.

[sylr]

https://github.com/hashicorp/go-getter might be relevent to this.

[FiloSottile]

Hi! Thank you for contributing! I took a different path in #173, but it was useful to look at open PRs for the users' expectations. Let me know if that implementation works for you!

I wrote up an explanation of why I ended up implementing recipient files and not HTTPS sources on the mailing list, and I appreciate feedback! https://groups.google.com/g/age-dev/c/StmWsOyb-H8/m/a44rSBIWCAAJ