Do not strip the controller in URLs for i18n landing pages

Do not strip the controller in URLs for i18n landing pages

Previously using an i18n CMS page as the landing page caused very odd behavior
as described in commit 0c03edef97240baa6374ce59e986245fb8ffedec.

Landing pages naturally cannot contain a language specific custom controller as
they don't have a controller within the URL, thus requests to the landing page
URL need to be dispatched to one of the languages in
ControllerMap::lookupDefaultController().

It was decided to dispatch to the user's current language which certainly is
the best solution from the UX perspective.

However this dynamic dispatch is problematic, because for i18n landing pages
the variant with the default language was also proclaimed to be the default
controller in ControllerMap::isDefaultController(), thus stripping it from the
language specific custom controller.

Ultimately this overloaded accesses to the landing page to both mean “the
default language” and “whatever language the user uses” at the same time,
unpredictably returning either a HTTP 200 or a HTTP 307 when canonicalizing the
URL in CmsPage depending on the user's language, ultimately dropping the
landing page from the search index of common search engines when it is crawled
in a non-default language.

Fix this whole mess by not stripping the controller from the URL for i18n
pages, allowing every language, including the default language, to have a
stable URL that will always return a HTTP 200 no matter the user's language.
The landing page will then dynamically redirect to the user's language,
preserving the UX enhancement without any of the drawbacks.