MacOS 11 performance improvements - this would benefit from some comments

Building against the MacOS 10.12 SDK gives us some bonuses.

1. It eliminates the jhbuild clause that prevents us from building the openssl module, even though the version provided by the SDK (pre 10.12) is old and missing features required by libnettle.
2. It includes some of the features we want in order to avoid MacOS 11's "dynamic" default 10-bit colourspace. So these changes are predicated on using the 10.12 SDK, while I'm leaving 10.9 as the "minimum supported OS version" for now.

Switching to this SDK "for real" is for a follow-up change, to the gimp-macos-build circleci config.yml file. This merge allows me to build locally, using the "official" samm-git gtk-osx repo instead of locally modified modules. I'd carry out a complete rebuild, if/once this merge occurs, to double-check a clean build and then push the config.yml change and trigger a new CircleCI build.

With that in mind, this merge includes:

1. libnettle fix - simply undoing the build flag I added last month as the SDK update eliminates the underlying issue
2. performance improvements - more controversial as this has some trading of performance for correctness.

I've included the code snippets mentioned in the issue tracker, that ensure GIMP windows are set to use 8-bit colourspace. This gets back something around 30% of the overall "lost" performance in Big Sur. The changes here (in gimp:gui.c and gtk+:gdk/quartz/GdkQuartzView.c) are protected behind a "Big Sur and newer" check.

But I've also includes changes (to gtk+:gdk/quartz/gtk*.c) that back out an earlier fix using the NSView lockFocus API. This API was deprecated in MacOS 10.14 and its use here triggers a complete window redraw (GdkQuartzView.drawRect:) for every event - including mouse moves. This is, to me, the main source of the lagginess/usability issues we've been seeing. Again, I've put them behind a "Big Sur or newer" check, so that I'm only impacting those who are affected by the issue, and not legacy OS users.

I've been using a version of the app locally for the last week or so with these changes in-place and I've not observed any weirdness, but that likely means I'm just not triggering the case(s) that led to the introduction of the lockFocus call in the first place.

I'm taking the GTK+ team note - about 2.24.33 being their last release of 2.x - seriously, so my little additions here likely won't make it into the main project, and I expect someone else will take care of this stuff for master (if they have not already).

And, yes, the change to gimp:gui.c likely could be merged into gimp:master or gimp:gimp-2.10 - but I wanted to see if we could eliminate the performance issue for the Mac port first.

Let me know what you think.