fix(admin): use a setting or permission item's own link

[GBra-4-669]

Fixes #5254

Changes proposed in this pull request:

Admin search ignores the link that an item can declare. Every setting and permission result goes to the group link, or to the page/extension route when there is no group, even if the item sets its own link.

Results now use the item's own link when it is set. The order is:

1. the item's link (an empty string counts as not set)
2. the group link
3. the page/extension route

This applies to:

• indexed settings (generalIndexItems('settings', ...))
• settings registered with registerSetting
• permissions registered with registerPermission

link is now typed and documented on SettingsComponentOptions and PermissionConfig. I also removed an outdated sentence about an "extra object" from the buildSettingComponent JSDoc.

Behaviour change: link on a registerSetting entry is no longer forwarded to the form field. It used to be passed through like any other attribute, so a third-party custom field component that used link as a prop would lose it. No setting in core or the bundled extensions sets link, so core should not be affected.

Not included: indexed permissions (generalIndexItems('permissions', ...)). That branch already throws in lookup() before any link is read. It is out of scope here and I can follow in a separate PR if you want.

Reviewers should focus on:

• link is used as-is and not validated. It's expected to be an admin route path such as the output of app.route().
• Whether registerSetting should accept link. The issue's Possible Solution suggests it, but I'm not sure it's the intended API.
• Not forwarding link to custom field components

Screenshot

N/A

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).
• Core developer confirmed locally this works as intended.
• The description above is written by me and describes what this pull request actually does.