dev/core#1713 - At end of upgrade, perform a system flush. Move menu-rebuild.

dev/core#1713 - At end of upgrade, perform a system flush. Move menu-rebuild.

Before
------

If/when an administrator opens the `civicrm/upgrade?reset=1` UI, then it rebuilds the menu (`CRM_Core_Menu::store()`).

This runs in upgrade-mode, so the menu does not include any routes defined via hook.

After
-----

At the end of upgrade, after the general schema has reached canonical form,
after most hooks are re-enabled for extensions, then it performs a full
system flush.  This incldues rebuilding the menu (and other caches).

Comments
--------

You might think that it serves some purpose to call `CRM_Core_Menu::store()` from
`CRM_Upgrade_Page_Upgrade::runIntro()`.  I can't figure one in the current regimen.  Consider:

* After loading a new source tree, do we need to rebuild the menu to
  access `civicrm/upgrade?reset=1`? Conceivably. But... if that's the case, then we
  wouldn't be able to visit `civicrm/upgrade?reset=1` at all. Moreover, the
  other upgrade routes (eg `civicrm/upgrade/queue*`) are hard-coded into
  the router specifically to resolve that chicken-egg issue.
* Code in `CRM_Upgrade_Page_Upgrade::runIntro()` only runs if you use the
  web-based upgrader (not headless upgraders). So that line isn't a reliable
  part of upgrade logic.
* When that old line runs, lots of hooks are disabled (incl `hook_xmlMenu` and `hook_alterMenu`),
  so it doesn't build a proper route table.
* Consider subsystems like Afform and Data Processor - which allow admins to define new pages.
  These routes have to be stored somewhere and then loaded programmatically (eg `hook_alterMenu`).
  The logic which reads the list probably involves APIs, database tables, and/or settings -- i.e.
  things that are not be reliably functional with old schema.