Remove fallback to wcf's custom URLs in ControllerMap::resolve()

Remove fallback to wcf's custom URLs in ControllerMap::resolve()

This fallback was introduced in the very first version of the forced redirect
to the custom URL for requests that directly request the controller class name
in c2de61fb187cf357cd9653693a8fa7cad39ca6ef.

However this might make controllers entirely inaccessible, because the custom
URLs are scoped to the application without any fallback to 'wcf'. This is
reproducible even in the 5.5 branch before the refactoring of the routing
logic.

Consider the following example:

- 'wcf' has the AccountManagementForm
- 'blog' also has an AccountManagement controller
- wcf's AccountManagementForm has the custom controller 'kontoverwaltung'

Now the following happens:

- Links to wcf's AccountManagement will be generated as /index.php?kontoverwaltung
- Links to blog's AccountManagement will be generated as /blog/index.php?account-management

So far so good, this is the expected behavior. Further:

- Accessing /index.php?account-management redirects to /index.php?kontoverwaltung

This is correct: The canonical URL is 'kontoverwaltung' and the page loads, however:

- Accessing /blog/index.php?account-management redirects to /blog/index.php?kontoverwaltung

This is not correct: The blog does not have a custom controller
'kontoverwaltung'. Due to the fallback in LookupRequestRoute, this will route
to wcf's AccountManagement. This fallback will be removed in PR #4873. If that
PR is merged, then instead of routing to wcf's AccountManagement, this will
result in a 404.

Either way: Blog's AccountManagement will be entirely inaccessible and
LinkHandler will generate broken links.

Fix this by removing this incorrect fallback. Accessing
/blog/index.php?account-management will now behave as if wcf's
AccountManagement wasn't renamed.