Navigation Block: Add option to show a hardcoded "dynamic menu"

[ryelle]

See #266 — Core navigation menus work by using a ref, an ID to a menu post. On the main site, this is fine, but on rosetta sites, this does not work because that post is not available on the local site.

For example, the About subpage should have a right-hand menu:

English	Rosetta

We could do some switch_to_blog work, but that would still load the English menu & links to the English site. Instead, I've added a new attribute to the Navigation block, menuSlug. When this is present (and not empty), the menu's content is swapped out for a hardcoded menu which uses the local site's base URL and wraps the menu text in translation wrappers.

I also added some styles for the vertical nav menu format, to match the list of links style, so we can use that on the About page (otherwise the links to the main English site were hardcoded).

Screenshots

Each menu in these screenshots are dynamically generated, linking to the page on the rosetta site.

Label	Screenshot
About
About subpage
Download
Download subpage

The dynamic menu doesn't have an in-editor preview, but the menu slug can be controlled in the editor — this at least prevents any regressions when the content is updated.

How to test the changes in this Pull Request:

1. About, Download, and the subpages should have visible menus regardless of whether those IDs exist on your local site.
2. Create or edit a page with a Navigation block on it
3. Switch it to use a dynamic menu
4. You should be able to control all the other settings (ex, layout & styles)
5. It should render that dynamic menu on the front end, with the settings applied

[adamwoodnz]

On insert the nav block chooses an existing menu, then when I change to one of the new dynamic options the block preview keeps the initial items. Can we update that?

[ryelle]

On insert the nav block chooses an existing menu, then when I change to one of the new dynamic options the block preview keeps the initial items. Can we update that?

I know 😞 I couldn't figure out a way around that, because if we delete the ref to the real menu, GB just tries to be smart and "fixes" the missing ref ID. If it's set to something arbitrary, the whole block fails to load. On the frontend, it should use the dynamic menu you selected despite the menu displayed in the editor.

I'll make a follow-up issue to figure this out, but I don't think it's a high priority fix since most people won't be editing pages with menus on them (the About & Download header menus have been moved out of the page content, so only the Download & About landing pages have them).