Clean up scripts and improve documentation to prepare for a release

[chrisfromwork]

This review contains the following:

1. Powershell scripts have been tested for Mac powershell environments. This resulted in fixes related to copying nuget package content
2. Azure spatial anchors has been moved to its most recent version
3. QR Code dependency downloads now remove included in editor c# initializer scripts. This is needed to unblock iOS builds (When dll initializer scripts fail for VCRT Forwarders and QR Code dependencies, they break post build processing steps required to obtain azure spatial anchors podfiles)
4. We now offer support for replacing symbolic links in the spectator view project with hard copies of external dependencies. This should unblock folks trying to build unity packages whose development environments don't support symbolic links
5. The native project's dependencies.props file logic has been cleaned up. We no longer copy sdks around. We also validate the inclusion of different components based on variables defined in the dependencies.props file.

TODO:
Before we can decalre an official release, two issues were discovered:

1. Android and iOS screen recording seems regressed with newer versions of OS and Unity
2. Synchronization of mrtk content does not appear to work correctly

[matthejo]

<DeckLink_inc>C:\Blackmagic DeckLink SDK 10.9.11\Win\include</DeckLink_inc> [](start = 4, length = 75)

These changes look unintentional?

[chrisfromwork]

They are intentional. We no longer require these SDKs to be relocated to the project for scripted building. Now we just default to the best expected location for these sdks.

Previously, we had hardcoded dll look up locations in build scripts. Now we use whatever a developer specifies here to resolve the location of these dependencies.

[matthejo]

(Test-Path $DependenciesPropsContent.Project.PropertyGroup.DeckLink_inc.replace($SolutionDirVariable, $SolutionDir)) [](start = 52, length = 116)

If the $(SolutionDir) is no longer in Dependencies.props, do you still need to do the replace here?

[chrisfromwork]

This step doesn't introduce any additional errors if $(SolutionDir) isn't specified. I'd like to keep this abilityin case paths do get specified relative to the $(SolutionDir) if developers change these dependencies.props locations in their local repo.

[matthejo]

Does this work for both file and directory symlinks? If it's intended for both, maybe a comment + naming the variables here $fileOrDirectory would make that clearer

[chrisfromwork]

Good question, we have not had any file symlinks to test with. This naming was based on the previous piped arguments higher up, so i will probably keep this as it is for now.

[matthejo]