Apple: Build as framework, and support visionOS

[dgovil]

This PR makes a few changes that have been derived from a corresponding PR to USD PixarAnimationStudios/OpenUSD#2969

The changes are:

1. Deprecates MATERIALX_BUILD_IOS in favor of using CMAKE_SYSTEM_NAME. This allows for better support for iPhone derived targets like visionOS. Earlier this would force it to iOS which can cause subtle issues when compiled against other SDKs. See https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-for-ios-tvos-visionos-or-watchos

2. Changes TARGET_OS_IOS define to TARGET_OS_IPHONE which is more correct to support iPhone derivatives. See https://chaosinmotion.com/2021/08/02/things-to-remember-compiler-conditionals-for-macos-ios-etc/ . But the gist is TARGET_OS_IOS refers specifically to the modern iOS/iPadOS SDK, whereas TARGET_OS_IPHONE refers to all Apple SDKs that derived from the original iPhone.

3. Add support for building as a Framework. This creates a special directory structure that streamlines embedding of MaterialX within Apps on Apple platforms to just dragging the project into the app in Xcode. No other linker and compiler configuration is necessary. See Framework notes below.

4. Adds a new getSharedLibraryPath function on Apple platforms that finds the path that contains the dylib, instead of just the executable that is ultimately linking to the dylib. I didn't implement this for Windows/Linux since there's only one the one need for it right now. This is derived from USD's method to do the same.

5. Additionally, I've added a MATERIALX_BUILD_IDENTIFIER that mirrors how USD generates a single integer build number for its namespace. I only use this within the Plist for the framework since it requires the identifier version to be an incrementing integer.

Framework notes

I have opted to use a zsh to keep this consistent with the PR for USD, rather than use CMake's built in Framework generation. This is also because, either way, I need to do some processing to the headers (see below) , fixing of linkage etc so it's simpler to just do it all in one spot.

Zsh is always guaranteed to exist on any macOS in the last several years.

The zsh script also modifies the Headers because Clang will automatically add frameworks to the include search path, as long as the include starts with the frameworks name. This means that #include <MaterialXCore/Document.h> now needs to be #include <MaterialX/MaterialXCore/Document.h>. However if your code requires the unprefixed version, you can still manually add the Header directory in the framework and it'll work as it normally would.

One other advantage to using the Zsh script as a post process is that you still get a standard build of the libraries too in case you want to use them otherwise, and you also can fix issues in the Framework without doing a full rebuild.

[jstone-lucasfilm]

@dgovil Should this changelist include corresponding updates to our GitHub CI, so that the new, recommended pattern for iOS builds is validated for current and future commits?

https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/.github/workflows/main.yml#L94

[dgovil]

Ah good catch, I'd missed that hidden folder.
Changed it over.

[jstone-lucasfilm]

This looks good to me, thanks @dgovil! I'm CC'ing @ld-kerley in case he has additional thoughts and recommendations.