macos: default to sRGB color space

[bakunowski]

Ghostty is currently using the native color space on MacOS. For some Apple devices that means DCI-P3.

When specifying a hex color, it gets mapped incorrectly, because the color space is about 25% wider. As an example:
#0000FF needs to be shown as "maximally blue in sRGB space". P3 is a much wider gamut, and the same hex code will result in a different color, since P3 can show "more blue".

A lot of useful information about this has been already written down in the following threads:

• Use sRGB color space for NSWindow on macOS alacritty/alacritty#6602
• Colorspace of truecolor renderings kovidgoyal/kitty#2249

To illustrate (screenshots taken on a 2021 MacBook 14" using "Digital Color Meter"):

Ghostty before this PR in native P3 color space:

Ghostty before this PR in sRGB color space:

Ghostty after this PR in P3:

Ghostty after this PR in sRGB:

Here's a side by side with onehalfdark in neovim:

Left is this PR, right is main

Color schemes are generally designed with sRGB in mind. onehalf for example specifies sRGB for iTerm2 and VSCode.

Behaviour of other terminals:

• iTerm (beta) allows to specify the color space, but it doesn't work in TUI applications, since (I suspect) they would also need to handle color spaces. This leads to a situation where onehalf would render correctly in the terminal, but incorrectly in neovim running in the same terminal. There's also a global config option to choose which color space to use. The stable release uses sRGB.
• Alacritty uses sRGB (post v0.12.0)
• Kitty allows to configure if sRGB or P3 is used globally.

[mitchellh]

Thank you for the background, it does look like at least Kitty and Alacritty set this same config for NSWindow. As I said in Discord, I'm far from a color space expert but there seems to be enough background on this that this makes sense. thank you!

[bakunowski]

Awesome! Thank you for pulling me into the beta. Been such a joyful experience 😄