Stop reading the configuration of a private module of one site

Problem/Motivation

Five configuration objects of myother — a module belonging to one site and published nowhere — are still read by this one: myother.settings:front_page in the normalizer and in the alias path processor, and myother.rewards, myother.front_ui_translations, myother.contacts_settings and myother.footer_texts in the static data and translation endpoints. A site installing this module has none of them, and no way to learn that it is expected to.

The front end address was the sixth and is already this module's own. What is left divides into two kinds: one value the module genuinely needs to do its work — which page is the front page — and four objects that are the content of one site's front end, carried by endpoints that exist to hand that content over.

Proposed resolution

• Read the front page from the site itself — core keeps it in system.site:page.front — and drop the foreign key. Where the two disagree today the site's own answer is the right one.
• Decide per endpoint what the other four are: either the endpoint declares the configuration object it serves, so any site can point it at its own, or the endpoint belongs with the site rather than with this module and is documented as such.
• Whatever is kept must degrade the way the rest of the module does: an absent object is an empty response, never a fatal and never a key holding NULL.
• Cover the front page reading with a test that a site configuring only its own front page is answered correctly.

Remaining tasks

Everything.