### Problem description
This PR implements some rudimentary Xcode support for building and
editing ImHex.
### Implementation description
#### Problem 1: Xcode is a multi-configuration buildsystem
The project is already rather CMake generator independent, thus it did
not need to change much to support Xcode's multi-configuration paradigm:
By default, CMake generates a `.xcodeproj` in which targets build their
artifacts into the specified `<>_OUTPUT_DIRECTORY`, postfixed by the
currently active configuration. To better fit the existing paradigm, I
instead opted ot introduce `IMHEX_MAIN_OUTPUT_DIRECTORY`. This variable
is equal to the previously used `RUNTIME_OUTPUT_DIRECTORY` when using
other generators, and is changed to include a configuration specific
_prefix_ when used with Xcode.
The result is different output directories when using Xcode, and no
changes when using any other generator.
#### Problem 2: ImHex does not support AppleClang
To allow building the codebase with Xcode, I have introduced
`IMHEX_IDE_HELPERS_OVERRIDE_XCODE_COMPILER`. Specifying this option to
`ON` will force CMake to honor the user specified compiler settings,
even when using the Xcode generator.
In practice this can be used together with the new "xcode" CMakePreset
to build the project with mainline clang using `xcodebuild`, or Xcode
itself by generating a buildsystem like so:
```
cmake --preset xcode -DCMAKE_PREFIX_PATH=/opt/homebrew/opt/llvm@17
```
This solution is of course not without flaws. The inner workings are a
particularly ugly hack, and mainline clang does not implement the
necessary extensions to allow Xcode to index the code. Regardless this
option is useful to enable future work in terms of bundling/signing
macOS applications in the "intended" way using Xcode without additional
source modifications.
#### Problem 3: Vanilla CMake + Xcode = Bad developer UX
By default, the CMake generated `.xcodeproj` is a mess. Tons of targets
are scattered about, and source files are not organized beyond grouping
them into a "Source Files" and "Header Files" group.
Even "Header Files" is missing, because the ImHex build system does not
regard private header files of libraries as sources of a target, and
Xcode does not try to guess this information.
The solution is twofold:
* Additional code has been added which organizes the targets into a neat
folder structure
* Additional code was added behind a configuration flag
`IMHEX_IDE_HELPERS_INTRUSIVE_IDE_TWEAKS` which automatically creates
source file trees in Xcode targets, and discovers the non-declared
header files via the folder convention.
### Screenshots
N/A
### Additional things
As a bonus: `IMHEX_OFFLINE_BUILD` assumes that ImHex-Patterns is cloned
into the source tree. I have added an additional fallback that tries to
locate it as a sibling folder of `${CMAKE_SOURCE_DIR}`, as this meshes
better with my filesystem setup.
The setup was tested with `CMake 3.29.2`, `Xcode 15.2`, and `llvm@17`
from homebrew.
### Problem description
#### Problem 1
In borderless mode ImHex disables the standard macOS titlebar rendering
and input processing. As a result double clicking the titlebar does not
trigger the native macOS behavior set in `System Settings -> Desktop &
Dock -> Double-click a window's title bar to [Zoom/Minimize/Do
nothing]`.
#### Problem 2
The ImHex window shows up as blank/transparent when de-minimizing it
from the dock.
#### Problem 3
Widgets experience ghost hover inputs from the past position of the
cursor during live resizing.
### Implementation description
ImGui elements consume input events in the order they are drawn. As a
result by "drawing" an `InvisibleButton` over the content area of the
titlebar we can catch unprocessed clicks in the titlebar area.
Connecting this button's double clicks to the native window is then a
trivial endeavour.
The blank windows was caused by the rendering stack clearing the GL
buffer, but proceeding to draw nothing in it. I have short circuited
this path.
Ghost hover inputs were squelched by consistently moving the ImGui
cursor to `0, 0` during a live resize. The OS will dispatch a cursor
positioning event once the resizing ends, restoring normal behavior.
### Screenshots
N/A
### Additional things
N/A
---------
Co-authored-by: Nik <werwolv98@gmail.com>
### Problem description
When the close button is clicked, `ImGui::BeginPopupModal()` sets the
bool passed into the second parameter (p_open) to false. However, the
closing logic did not take this into account, making it difficult to
actually close modal popups.
For example, closing the "Export pattern File" modal took several clicks
on the "X" button, now it closes instantly.
### Implementation description
I added an additional check for the `open` variable being `false` in the
logic that checks the closing condition.
### Problem description
The framerate limiter doesn't work when inputs are being sent (eg mouse
cursor moving over the window), because `glfwWaitEventsTimeout` returns
early when it encounters an event.
### Implementation description
I made it sleep for the remaining time when that happens.
