lookup default browsers via UrlAssociations\https\UserChoice if protocol is not http/https. ensures webbrowser.open launches a web browser on Windows, even for URLs that are not http[s]. Only does the lookup for non-http URLs, limiting the impact of the change.

ensures browser is opened for e.g. file:// URLs, where startfile opens file by association. Launching custom protocols explicitly goes through the browser instead of through startfile. The end result is usually the same, after a prompt, unless the browser has explicit support/configuration for the protocol. Alternative: only lookup for file:// instead of not http[s]://.

Added extremely basic test exercise, the registry lookups are not actually covered, but I have tested them by hand. I'm not sure how to write good tests for the registry stuff.

Addresses gh-128540 on Windows only.

Open questions:

• custom URLs: os.startfile("ssh://some-host") might start putty or something, whereas this explicitly launches the browser (which would in turn typically prompt "launch external application PuTTy..?"). Behavior for custom URLs is previously undefined and inconsistent, but after this PR, it consistently launches a webbrowser if it can, but remains undefined.
• are there more ways/times/versions for this to fail? It works in my tests, but I don't know all the different situations on Windows wrt versions, permissions, UWP, etc.
• Can the open command-line lack %1 and still be valid (e.g. with append)? I can't find a spec for this, so it would be good to know. I've gone with the most conservative, which is to assume it doesn't work if %1 is not present, falling back on previous os.startfile in that case.

Links:

• More discussion in https://discuss.python.org/t/support-for-file-urls-in-webbrowser-open/81612
• Backported implementation for testing in https://pypi.org/project/webbrowser-open/
• macOS counterpart: gh-128540: lookup default webbrowser on macOS #130535
• Linux counterpart: gh-128540: launch default browser more often on Linux #130541