Respond in request content type for 404 in development/test
Respond in request content type for 404 in development/test

When the API routes used a globbing pattern, routes that were "not
found" were handled directly in the `ApiController` itself, and served
up in a JSON format.

Since the routing is now handled by Rails' routing, "not found" routes
are handled by ActionDispatch. In development/test, this serves up a
standard response in HTML format, regardless of the requested content
type.

From the docs:

> config.consider_all_requests_local is a flag. If true then any error
  will cause detailed debugging information to be dumped in the HTTP
  response, and the Rails::Info controller will show the application
  runtime context in /rails/info/properties. True by default in
  development and test environments, and false in production mode. For
  finer-grained control, set this to false and implement local_request?
  in controllers to specify which requests should provide debugging
  information on errors.

By setting the above value to false in development/test environments,
and indicating that all requests are considered local in
development/test in `ApplicationController`. Any other requests ("not
found") are not considered local, and hence will be served back the same
response you would see in production, which respects the request content
type. In other words, if you hit an unrouted URI in your browser, you'll
see some HTML, and if you've requested JSON, you'll see a JSON response.

One drawback to this approach is that you won't see any detailed debug
information for 404s, but that may not be much of a drawback.

I also considered the newer config option
`debug_exception_response_format`. Unfortunately, this wasn't
sufficiently flexible - it can either be set to `:default` which
preserves the existing behavior, or `:api` which will serve up JSON
responses for all 404s regardless of the request type, which seemed
undesireable (at least while the app is still supporting server-side
HTML rendering).

Another alternative would be to provide a new route which globs all
requests in the /api namespace and routes them to a special action which
handles 404s for URIs that have not been matched by an existing
route. This would be most similar to what came before, but means we have
to maintain this code (whereas I think there are opportunities for
deletions in the proposed solution), so I am trying to fallback on what
Rails provides as a first attempt.

Fixes https://github.com/ManageIQ/manageiq/issues/9869
(transferred from ManageIQ/manageiq@7da418132106e94b22531fae9faeac5d4bb8b810)

ManageIQ/manageiq-ui-classic,ManageIQ/manageiq-ui-classic,ManageIQ/manageiq-ui-classic,ManageIQ/manageiq-ui-classic