Offer a more appropriate default Page heading and Slug when Pages are not the root node of a site

[CrispinF]

See #520 for test workflow. The issue is that when a site is started up in this mode, the root navigation node is given the name "Home" using controller "Home". Then when an admin tries to create the first Page, no matter what they have called the Pages root while making the solution from the template (default "Articles") the new page is given default Page heading and Slug of "home". This does work, but it's very confusing.
But if the user changes the defaults while making the page, the menu link now fails to find the new page as the site's Content Settings still say the Default Page = "home".
Various solutions to consider here, including perhaps:
When we add storage e.g. services.AddNoDbStorageForSimpleContent(); we could make a default Page with a heading and slug matching the chosen Pages menu text. And the site setting for Default Page could be set to match. This would avoid an admin having to make this page at all. Perhaps this would require passing a parameter in here with the chosen menu text.
If that isn't possible, well the /editpage is clearly aware of this situation and giving these default "home" values for the first page... so perhaps this can itself lookup the chosen menu node name, and potentially also change the site settings default page. This feels less likely to come out nicely than the first approach.

[JimKerslake]

For the moment I have changed that default slug to 'page1' and the title to 'Page 1' if any site mode other than the default "pages as default route" is selected during site creation. It remains 'home' for the default option.

If we want to capture 'Articles' (as input by template user) then it will require another template release, capturing a new appSetting and setting its value to that input variable, which is achievable, but a rather larger undertaking.

---

Notes to self -
Add option to ContentSettingsUIConfig

(The stored boolean UseDefaultPageAsRootNode is always true and no code path ever to set it false - except perhaps by user override in json before first site spin-up.)

[JimKerslake]

cloudscribe.SimpleContent.Web 5.1.6
and
cloudscribe.Core.SimpleContent 5.1.4

[JimKerslake]

Note for testing - retrospective upgrading of the above nugets in a site that has already spun up will have no effect, because the default page slug is migrated into cs_ContentProject at first spin-up.

[JimKerslake]

Further to above - the code looks as though it should be possible to read these settings in from json config:

  "ContentProjects": [
        {
            "ProjectId": "5ca7ceca-b73d-49bc-9b8f-b3d40e748a4d",
            "DefaultPageSlug":  "whatever"
        }
    ],

...but I'm not seeing that working at all.
The registered IProjectQueries query class always seems to get these from the Db instead.

Actually these look like alternative implementations of IProjectQueries, so you can register them into the DI pipeline in startup extensions - but only one or the other gets used. Either Db or Json is in charge of these settings.

And further again - the above is only potentially available in NoDb (though it isn't wired up to work in that mode either by default). Looks like the database is mostly in charge, for these settings, in general.