frontend: Add support for TEB/Multitrack Video to macOS (arm64 only)

[dsaedtler]

Description

Adds TEB support for macOS on Apple Silicon.

Motivation and Context

Want to support all users, including macOS/Linux (Linux tbd).
The small number of SKUs makes Apple Silicon easy, and since Intel Macs are losing support it seems fine to only support ARM.

Note: GetClientConfiguration API changes have not yet rolled out into production.

How Has This Been Tested?

Locally with Twitch staging environment.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[dsaedtler]

Configuration API support for macOS is now rolling out into production, within the next few days this PR should be testable by anyone.

[dsaedtler]

The server-side changes have now rolled out, so this PR can be tested by anybody who wishes to do so!

[RytoEX]

We should probably add a license header to frontend/utility/system-info-macos.mm. That need not be done here, but it would be fine to include here.

Prefix should be frontend: .

@PatTheMav I'd appreciate a quick glance to make sure the includes/imports are as preferred.

[PatTheMav]

You can just use #import everywhere, there is no technical reason not to for ObjC except for possible cosmetic reasons.

Also correct order per the new rules (case-sensitive sort if there is no technical reason for a different order) should be:

#import <Foundation/Foundation.h>
#import <Foundation/NSProcessInfo.h>
#import <sys/sysctl.h>
#import <sys/types.h>

[dsaedtler]

You can just use #import everywhere, there is no technical reason not to for ObjC except for possible cosmetic reasons.

Yeah I just kept using include for C and import for ObjC, but I can change it for both.

Also correct order per the new rules (case-sensitive sort if there is no technical reason for a different order) should be:

Are these "new rules" documented anywhere?

[PatTheMav]

Only by example, all new frontend files' includes have been arranged that way (and if they aren't it'd be an error).

The general order:

1. Header associated with source file
2. Other header files from the same project
3. Header files from non-standard library
4. Header files from standard library

Is more or less an established good-practice anyway. Sorting case-sensitive has the additional benefit of putting C++ classes (or in this case ObjC frameworks) as high-level language objects before low-level language objects almost automatically.

Thus the order of includes on a micro-level align neatly with the order of includes on a macro-level:

1. Headers associated with larger frameworks or classes, mostly OO
2. Headers associated with bare code and type definitions, mostly non-OO

So the further down in the includes, the more "low-level" the include is.