#25277 Non-existant app level hooks are now ignored in inheritance chain
Previously, whenever a new-style hook was executed, it would (regardless
of whether the get_baseclass call was used or not) build up an
inheritance list and load each of the class objects in those files
(cached, so only loaded once). If a file didn't exist, an exception was
raised. This is normally not an issue since hooks specified in configs
certainly must exist and default hooks that come with apps also need to
exist. However, if the {engine_name} token is used in the manifest,
there is a case where an app does not provide a default hook for an
engine - beause it doesn't officially support it yet - and therefore an
exception was raised beucase that file was missing. 

The logic is now tweaked so that the code checks if the default app hook
exists and only then will it wedge it into the inheritance list. This
means that the get_baseclass call will return the main Hook class as
long as the app does not provide default support for that engine, and
when a version of the app which does support the new engine is released,
the get-baseclass call will start returning that default hook instead.
This transition should be harmless for already existing custom
implementations since they need to completely implement the required
hook interface anyway, and therefore will shadow the (new) default base
class implementation.