Simplify `osascript` handling

[sellout]

This makes a few changes, somewhat independent, but all related:

• defaults auto-dark-allow-osascript to true[^1];
• falls back to osascript on-demand if neither ns-do-applescript nor mac-do-applescript is available[^2]; and
• removes osascript as a separate auto-dark-detection-method[^3].

These can be easily separated depending on which, if any, you think are improvements.

[^1]: I don’t know why this is even a variable. If it’s not allowed, then there is no way to use Auto-Dark on systems that require it, and the failure mode is opaque (“Could not determine a viable theme detection mechanism!”). There’s probably something I’m overlooking, but if so, it should be documented.

[^2]: If this change isn’t made, then the error message “Try setting auto-dark-allow-osascript to t” doesn’t make sense, as it’s only reported in a location where the value of auto-dark-allow-osascript has no effect. The alternative is to change the error message to something like “auto-dark-detection-method indicates that this Emacs build has AppleScript support, but none could be found. Either rebuild Emacs with AppleScript support or change the detection method and set auto-dark-allow-osascript”.

[^3]: With #59, the two fboundp checks added before falling back to osascript should be more than outweighed by the removal of shell invocation.

[sellout]

Another question I had somewhat related to this …

I had considered unifying the osascript and powershell management under a single auto-dark-allow-shell variable, but one thing that stopped me was noticing that while osascript is a last resort, powershell is preferred over reading directly from the registry. Why is that? It seems like powershell is simply doing the same thing w32-read-registry is doing, but indirectly, and we don’t have the (fboundp 'w32-read-registry) check like we do on the Darwin side of things, so why does the powershell detection method even exist?