Restore missing handbook pages after #12411

[dd32]

Description

Following on from #12411 and #11817 it was noticed that some pages were skipped, as they weren't included in the toc.json file previously.

This PR includes several specific fixes which are all interconnected:

1. Adds the Internationalization page along with the Block Tutorial to the handbook hierarchy
2. An additional landing page for the Tutorials index was added
3. Components was added to the developers handbook alongside Packages and Data Package Reference pages.
4. In order to handle the above move, the duplicative declarations of Packages, Data Package Reference and Components were removed from docs/tool/manifest.js to prevent them adding as top-level-items. (Are these intended to be top-level-handbook-pages or deep within the developers handbook as the TOC seems to suggest?)

I also took the opportunity to convert generate.php from the previous PR into a JS command that allows for docs/root-manifest.json to be removed entirely and dynamically generated from docs/toc.json so it only needs updating in a single location. That's the getRootManifest() and generateRootManifestFromTOCItems() functions which are rather messy, but work (I'm sure someone else could clean that up significantly).

How has this been tested?

The only testing done so far is the manual review of the final docs/manifest.json.

[chrisvanpatten]

Ha, @pbiron and I were having a call today to discuss porting the PHP generator to JS today but you beat us! I’ll review this within the next hour. Thanks @dd32 for helping so much on this; you rock.

[chrisvanpatten]

(Also @dd32 how much bandwidth do you have if I have some additional improvements here? Don’t want to overwhelm you with review comments because at this point anything is an improvement and I wouldn’t want this to linger too long!)

[chrisvanpatten]

Approving because this is all great, and nothing that explicitly needs to be changed here.

I did add a review note about a new "wildcard" option. That can be addressed here or in a follow-up PR, but I think that's a crucial final step to getting our docs generator in order.

[chrisvanpatten]

So one idea here with the packages and data docs and components docs is supporting some kind of wildcard here, e.g.:

{"packages/components/README.md": [
  {"packages/components/*": []}
]},

This would allow us to separate the build and the manifest generation, such that there's a distinct build step that generates or syncs the markdown files into the docs/ folder, and then a separate step for adding them to the manifest.json.

(It's a wildcard rather than explicitly listing files here to allow us to have sections of documentation where the files inside the nesting level may change but the documentation's order doesn't matter. Just a way to simplify a bit here.)

Does that make sense as a way to improve here?

[chrisvanpatten]

Coming back to this, the components and packages documentation offer some weird pieces here because their documentation lives outside the docs folder and can be quite structurally different.

I guess you'd need to either support full globbing, e.g.

{"packages/components/README.md": [
  {"packages/components/**/*": []}
]},

OR… we would have an explicit build step that copies the components/packages documentation into the docs folder first, then a simple wildcard could be used that references the documentation as it exists inside docs, rather than referencing it from elsewhere in the repo.

Thinking out loud, at this point :)

[dd32]

Also @dd32 how much bandwidth do you have if I have some additional improvements here?

I don't have a huge amount of bandwidth for it right now, I also doubt I have the JS experience required to make such changes honestly. Happy to review or test things though.

[chrisvanpatten]

@dd32 totally fair! In that case I’d say let’s merge this and we can iterate later 🙌