[imorland]

Fixes: no issue filed.

Changes proposed in this pull request:

Browsers can't add a Flarum forum as a search engine, so searching it from the address bar means opening the forum first. This adds OpenSearch support.

• Description at /opensearch, linked from every page with <link rel="search">. It names the forum, gives the search address (/?q={searchTerms}), a suggestions address and its own address for updates, and embeds the favicon as a 16px .ico and a PNG of at most 64px. Embedded, the icon stays under Firefox's 10KB limit for linked icons and doesn't depend on where assets are served. Served by Flarum without an .xml extension, which Flarum's suggested nginx config would only look for on disk.
• Suggestions at /api/opensearch/suggestions, in the OpenSearch suggestions format: titles of discussions the visitor can see, with their addresses. Titles are matched on the start of their words, so a word is completed as it's typed. The forum's search matches whole words on MySQL, MariaDB and PostgreSQL, so it can't suggest anything until a word is finished.
• Short Name on the Basics page, up to 16 characters, which OpenSearch requires. Without one, the forum title is used, cut at the last whole word that fits. The web app manifest from feat: app icon, .ico favicon, web app manifest, and logos and icons set by themes #5319 uses it as its short_name.

Reviewers should focus on:

• Suggestions run their own title query rather than going through the search manager. They need at least two characters, return up to eight discussions, and are cached privately for a minute. They live under the API, so any rate limiting an extension adds to the API applies to them.
• Chrome only picks up a description on a site's root page, and adds it as an inactive shortcut that must be turned on in its settings. Firefox offers it from the address bar, and only fetches suggestions once it's installed.
• Chrome 156 picks up the forum, searches it and requests suggestions as you type. Firefox 158 offers it from the address bar and searches it.

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Frontend changes: tests are green (run yarn test in js/).
• Frontend changes: tests have been added, or are not appropriate here.
• Backend changes: tests are green (run composer test).
• Backend changes: tests have been added, or are not appropriate here.
• Where applicable, changes are suitable for all supported database drivers (MySQL, MariaDB, PostgreSQL, SQLite). (Suggestion tests run on MySQL and SQLite; PostgreSQL relies on whereLike() using ILIKE.)
• Core developer confirmed locally this works as intended.
• The description above is written by me and describes what this pull request actually does.