OpenSearch support

[The-Compiler]

To make it easier to add search engines, OpenSearch should probably be supported, with a :searchengine-add command or so to add the engine.

This should probably be done after the config migration (#499).

There's opensearch on PyPI, but maybe parsing the bits we actually need from hand (via xml.etree or Qt classes) might be easier.

[The-Compiler]

Some kind of subtle icon could also be shown in the status bar, to make it clear there actually is custom search engine support - I got feedback by someone who wasn't aware of that.

[wasamasa]

Meanwhile, I've figured out a workflow to make manual migration from OpenSearch (as found via Mycroft) to Qutebrowser a bit easier:

• Have an ID of the Mycroft search ready (like, by hovering over the entry)
• Enter ID on http://mycroftproject.com/submitos.html and click the "Load" button
• Copy URL from "Search URL" field
• Delete "searchTerms" in it
• Use URL in your config file
• Repeat steps until done

[The-Compiler]

In #6049, @samyak-jain mentioned:

Regarding xml parsing, your concerns are fair. The official python docs seem to recommend https://pypi.org/project/defusedxml/.

Perhaps we can still get away with xml.etree from the stdlib though, see the XML vulnerabilities part of the stdlib docs. I'm not too worried about Denial of Service attacks, especially as long as we have some kind of :search-engine-add (or whatever) command and don't automatically parse them. Chances are there are other vectors how websites could bring the browser process to its knees. As long as other attacks (notably including local files) aren't a problem, I think that's a fair trade-off.

[samyak-jain]

@The-Compiler Yeah, looking at the vulnerabilities, I agree. Like @rcorre mentioned in #6049, Billion laughs/exponential blowup shoudn't be a major problem for us so I think we can get away with using etree.