Quicker Mac builds by removing dependencies

[kettle11]

This PR is not ready to go, but I wanted to create a pull request to have a record of the concept. It might be useful as a point of reference even if not directly used.

This change removes direct dependencies on the cocoa, core-foundation, and core-graphics crates by copy-pasting the used parts from those libraries directly into winit.

On my M1 Mac Air this dropped release build times from ~3.95 seconds to ~2.7 seconds.

No functionality was changed other than one tiny segment of code that I was too lazy to figure out how to port over.

For this to become a real PR it would need a few things:

• More organized copy-pasted code. I didn't have a formed strategy when I started out so the structure is all over the place.
• An evaluation and plan of the ongoing maintenance burden added by this approach.
• A fix for that one spot I was too lazy to port correctly.
• Consideration of how to properly attribute the libraries copied from.

[madsmtm]

Thanks for the idea! On my machine a clean build goes from ~18s to ~10s, so this would be nice!

However, I don't think the tradeoff is worth it - in part because I think I want to move towards using something else entirely (like cacao or something), but mostly because I don't think we can really cope with such a massive added maintenance burden.

(I know I argued strongly for low build times in #2057, but that was when the difference needlessly went from 13 seconds to around 1 minute).

(Also, this would solve #1816).

[kettle11]

There's definitely added maintenance burden so it's reasonable to not pick this approach but I don't think it's as massive as it seems initially.

I say that for a few reasons:

• Many (most?) of the lines in the above PR are commented out and the change could be reduced substantially
• It's probably not super common that a new system API is needed, and it's only a slight effort to find new needed bindings and copy-paste them into Winit.
• The code copied is all relatively simple, so it's less likely to regress dramatically.
• It's also unlikely the underlying binding crates are going to be fixed or updated in ways that leave Winit behind.

I think the biggest cost is that when adding new functionality to Winit that requires new bindings there's a non-trivial amount of friction that makes implementing that new functionality slightly more frustrating. This might slow continuing maintenance.

[madsmtm]

I grabbed part of core-video-sys in #2326 because it was going stale, that should help at bit, but I don't think I'll be replacing cocoa, core-foundation and core-graphics just yet - I have other plans for how to do this (mainly, I want to replace them with a safe abstraction!).

Still, thanks for the PR!