bpo-43137: Revert "webbrowser: Don't run gvfs-open on GNOME"

[smcv]

gvfs-open was deprecated in 2015 and removed in 2018, but its replacement,
gio(1), is not available in Ubuntu 16.04, which is apparently still
supported by CPython upstream even though it is considered to be EOL by
Ubuntu developers.

https://bugs.python.org/issue43137

[smcv]

As requested on https://bugs.python.org/issue43137 by @pablogsal. cc @tiran, @jaraco

I am not a CPython developer, so I cannot assess which reviewers' requirements are blockers and which are nice-to-have. Please agree on what you want from me, and then merge, or don't, as you prefer.

If the CPython infrastructure hadn't squashed the three commits in my original PR #29154 into a single commit, then this would have been easier (it's a revert of the last commit, aed1ba5).

If compatibility with truly ancient distros (pre-2008) is desired, you could also revert 251ea9c if you want, but I personally think that's a bad idea.

[pablogsal]

I am merging this to unblock the release.

@smcv Thanks for the original PR and for this revert. Please, check with @tiran about how to modify your original PR to ensure it works on all supported platforms.

[smcv]

Note that this is not a complete revert of #29154. I made three changes in #29154, and this PR only reverts the third one:

• 4fd89aa: Prefer gio open over gvfs-open (this is the actual bug-fix for bpo-43137)
• 251ea9c: Never invoke gnome-open (cleanup; breaks compatibility with approx. pre-2010 distros)
• aed1ba5: Don't run gvfs-open on GNOME (cleanup; breaks compatibility with approx. pre-2016 distros; reverted in this PR)

I hope the end result, equivalent to applying 4fd89aa and 251ea9c but not aed1ba5, is acceptable to everyone.

If not, please tell me what would be acceptable. I have tried to be as clear as possible about what each commit does and why, so that reviewers can accept them or not as they prefer, but I don't know CPython development practices well enough to guess at what is required from me beyond that. Was I meant to submit these changes as three separate PRs that depended on each other, so that reviewers could accept the first one or two but reject the third if they wanted to?