We can't hook some modules' methods

[Steven Michaud]

Thinking about process_hook_rising() and process_hook_falling(), I realized there's a problem:
As things now stand, modules can get loaded without our having a chance to set hooks in them.

In process_hook_rising() we set up a call to dyld::runInitializers() to run the hook library's C++ initializers after we return to user space. And later (in process_hook_falling()) we set up a call to _dyld_register_func_for_add_image() to register a callback that tells us when a new module is loaded. But if any of the hook library's C++ initializers (or those of its dependencies) call dlopen(), they may load modules that our callback never sees (since it hasn't been registered yet).

The solution, I think, is to consolidate process_hook_rising() and process_hook_falling() into a single method -- process_hook_flying(). We'll also need to replace hook_state_rising and hook_state_falling with a single state -- hook_state_flying. We'll lose the ability to run our hook library's C++ initializers separately, before those of the main executable. But as best I can tell that doesn't matter.

The hook library's C++ initializers (and those of its dependencies) will now run from dyld::initializeMainExecutable(), mixed in with those of the main executable. This might result in the hook library's C++ initializers running a little later. But its dependencies will mostly also be dependencies of the main executable. So mostly it should make no difference.

I'm about to land a patch that fixes this problem.