fix(upgrade): check for other extensions in flarum.extensions

[imorland]

Fixes: no issue.

Changes proposed in this pull request:
1.x code checked whether another extension was enabled with app.initializers.has(name). An initializer isn't always named after its extension, and 2.0 renamed three of core's (flarum/framework#4003), so checks like fof/username-request's has('flarum/nicknames') are always false in 2.0. The misc frontend step was meant to rename those three, but it never ran. It only ran on files containing this.currentTag, and an earlier change in the same step had already rewritten that. Now app.initializers.has('name') becomes 'id' in flarum.extensions wherever the ID is certain: a bundled extension's, or one the extension's composer.json names (in require, require-dev, suggest or optional-dependencies), by its ID or its package name. Any other check gets a @TODO, placed above its statement so it can't land inside JSX.

This also fixes the step machinery. When a replacement changed the code as text, a later replacement in the same step still got the syntax tree from before that change. If the later one returned that tree, the text change was lost. Across the corpus that dropped changes in four real form modals, for example Sami's SearchState import move in fof/byobu's AddRecipientModal.

Reviewers should focus on:

• Why not convert every check: in 385 real 1.x initializers, 30 aren't named after their extension or its package (e.g. gtdxyz-flarum-badges), so converting blindly would turn working checks into ones that are always false.
• Corpus (197 real 1.x extensions): of 24 checks, 21 converted and 3 got a @TODO. All three are third-party extensions their callers don't list in composer.json. With and without the machinery fix, the frontend steps give the same output for 6,234 file runs, except the four modals above.

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 on the 1.x code of fof/username-request, fof/impersonate and datlechin/flarum-scroll-buttons.)
• Frontend changes: tests are green (run yarn test in js/). (yarn test: 295 tests, plus Prettier, ESLint and tsc.)
• Frontend changes: tests have been added, or are not appropriate here. (7 new tests, all seen failing first.)
• 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.