feat(upgrade): register admin settings, permissions and pages with Extend.Admin

[imorland]

Fixes: no issue.

Changes proposed in this pull request:
Flarum 2.0 registers an extension's admin settings, permissions and page with Extend.Admin in admin/extend. A new step, after the misc frontend step, moves the app.extensionData.for(…) / app.registry.for(…) chains an admin initializer runs into admin/extend (a new one, or the one the index already exports) as setting(() => …), customSetting(…), permission(() => …, type, priority) and page(…), along with the imports and literal constants they use. It moves them only when they would do the same thing from there. Otherwise all of the extension's registrations stay where they are, with a @TODO saying why. The initializer itself stays, because other extensions may check for it by name.

The misc step now renames every app.extensionData in a file, not just the first. Nine real 1.x files use it more than once (fof/blog, for example), and in 2.0 the uses it missed crash. It also renames getAllExtensionPermissions() to getAllPermissions(), the method's 2.0 name.

Reviewers should focus on:

• When it leaves things:

  • a registration uses something the initializer declares, or a type the file declares;
  • other registry use runs as the admin boots (in an if, or in another admin file);
  • it can't add to the extend file.

  Moving only some would change their order, so it is all or nothing for each extension.

• I tested it on 197 real 1.x admins (bundled, 84 FoF, 98 third-party): 161 moved, 23 were left with a @TODO, and 13 had nothing to move. In every one that moved, each registration became exactly one extender method, and nothing lost its import.

• For 40 FoF extensions the result is the same as their hand-ported 2.x extend file. The other 24 differ only where the port changed things: pages rewritten as settings, new settings, new priorities.

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? (N/A)
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation. (The built CLI ran the misc step and this one on the 1.x admins of Likes, Gamification, Blog, Follow Tags and Syndication. Four moved, and one was left with a @TODO. Running the step again changed nothing.)
• Frontend changes: tests are green (run yarn test in js/). (yarn test: 288 tests, plus Prettier, ESLint and tsc.)
• Frontend changes: tests have been added, or are not appropriate here. (21 new tests. All but one were seen failing first. The exception checks that an index with nothing to move is left as it is.)
• Backend changes: tests are green (run composer test). (N/A)
• Backend changes: tests have been added, or are not appropriate here. (N/A)
• Where applicable, changes are suitable for all supported database drivers (MySQL, MariaDB, PostgreSQL, SQLite). (N/A)
• Core developer confirmed locally this works as intended.
• The description above is written by me and describes what this pull request actually does.

Required changes:

None.