Hook window created functions

Just some thoughts for now..

This has previously come up during discussion with regards to the rules and signal system provided by yabai. A common annoyance is the fact that signals are executed *after* yabai has handled an event internally. When using signals to customize tiling behaviour (utilizing `window_created` events) there will be visual screen flicker as yabai first tiles the window using its own logic, before eventually being overridden by whatever the user scripted in their signal handler.

I think signals work fine for the most part, however the `window_created` event in particular needs to allow the option to pre-empt the internal logic. This could work as follows:

Some new window is created by macOS, yabai does some mandatory internal stuff and checks whether there is a configuration present to do something upon window creation. If yes, exec the external script and defer handling of said message until the user script has finished executing.

The user script would return a string to stdout that is a list of space-separated key-value pairs following the same structure as window rules do today. These properties would then be applied to the window, before the *should manage window* logic runs. Empty string should be allowed, to keep properties as is.

In this user script it would be fully possible to utilize the query system to retrieve more information about the window, and otherwise call arbitrary yabai commands. Maybe this in itself is enough and the key-value pair configuration isn't really necessary. In that case the user script needs to return a status indicating if the event was handled correctly by the user, or if it should default to the internal logic.

The goal of this is to make the automatic tiling easier to control for people who do not like the "default" way that yabai splits and positions windows. In this script you could query the number of windows, adjust padding, adjust the split ratio, change the split type, change which existing window should be split/inserted at. Maybe move the window to a second display or a new blank space, depending on how many windows are already visible, etc.

This probably also applies to application launch, which could result in multiple windows; there would likely be a separate invocation for every window.. need to think some more to determine the appropriate behaviour.

Start with the existing window_created signal path, window-rule handling, and query system; the issue does not name specific files or tests. Resolve whether the hook returns window properties or only a handled status, and define fallback behavior for empty or unsuccessful responses. Done means window creation can be pre-empted without visual flicker while retaining default handling when the hook does not handle the event.

Written by the indexing model from the issue text.