OpenImageIO link error when building on macOS

I recently noticed that there is a macOS branch so I decided to try building it to see what would happen. Unfortunately I was not able to get past running installExternals.py so I am wondering if this branch is still a work in progress that is not yet ready for public consumption. It's not a problem if that's the case, but I would love to use it when it's ready.

As for the error I'm seeing...

I am running the following installExternals.py command line when I received the error below:

`python Scripts/installExternals.py --generator Xcode --build-variant Release ../AuroraExternals`

And here is the error I received (the full log output is [here](https://github.com/user-attachments/files/17344063/log.txt)):
```
ld: warning: search path '/Users/thayerdev/Documents/Development/GitHub/AuroraExternals/boost/lib/Release' not found
Undefined symbols for architecture arm64:
"boost::filesystem::detail::directory_iterator_construct(boost::filesystem::directory_iterator&, boost::filesystem::path const&, unsigned int, boost::filesystem::detail::directory_iterator_params*, boost::system::error_code*)", referenced from:
OpenImageIO_v2_5::Filesystem::searchpath_find(std::__1::basic_string, std::__1::allocator> const&, std::__1::vector, std::__1::allocator>, std::__1::allocator, std::__1::allocator>>> const&, bool, bool) in filesystem.o
OpenImageIO_v2_5::Filesystem::get_directory_entries(std::__1::basic_string, std::__1::allocator> const&, std::__1::vector, std::__1::allocator>, std::__1::allocator, std::__1::allocator>>>&, bool, std::__1::basic_string, std::__1::allocator> const&) in filesystem.o
OpenImageIO_v2_5::Filesystem::scan_for_matching_filenames(std::__1::basic_string, std::__1::allocator> const&, std::__1::vector>&, std::__1::vector, std::__1::allocator>, std::__1::allocator, std::__1::allocator>>>&) in filesystem.o
"boost::filesystem::detail::recursive_directory_iterator_construct(boost::filesystem::recursive_directory_iterator&, boost::filesystem::path const&, unsigned int, boost::system::error_code*)", referenced from:
boost::filesystem::recursive_directory_iterator::recursive_directory_iterator(boost::filesystem::path const&, boost::system::error_code&) in filesystem.o
"boost::filesystem::detail::copy(boost::filesystem::path const&, boost::filesystem::path const&, unsigned int, boost::system::error_code*)", referenced from:
OpenImageIO_v2_5::Filesystem::copy(OpenImageIO_v2_5::basic_string_view>, OpenImageIO_v2_5::basic_string_view>, std::__1::basic_string, std::__1::allocator>&) in filesystem.o
"boost::filesystem::detail::absolute(boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*)", referenced from:
OpenImageIO_v2_5::Filesystem::find_program(OpenImageIO_v2_5::basic_string_view>) in filesystem.o
OpenImageIO_v2_5::Filesystem::find_program(OpenImageIO_v2_5::basic_string_view>) in filesystem.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

I am curious if the initial `ld: warning: ...` message is relevant. It seems like it's not since the boost libraries are being referenced in the linker arguments with full paths and ld seems to be finding them correctly.

When looking through the full log output I see that `/Users/thayerdev/Documents/Development/GitHub/AuroraExternals/boost/lib/libboost_filesystem.dylib` is present in the linker arguments, this file does exist at that path on my disk, it is an arm64 dylib, and when I run nm on it I can see that `directory_iterator_construct` is a defined symbol. So I'm not sure what might be wrong but so far I'm unable to get past this obstacle.

I am building with the following setup:
M1 Mac Mini
Sonoma 14.5
Xcode 15.4
CMake 3.29.8
Python 3.11.4

Start by reproducing `python Scripts/installExternals.py --generator Xcode --build-variant Release ../AuroraExternals` on the stated macOS and Xcode setup, then inspect the linked full log and the missing `boost/lib/Release` search path. Done means the external-dependency build completes without the OpenImageIO arm64 linker errors.

Written by the indexing model from the issue text.