[Housekeeping] Add Benchmarks to GitHub Actions

[TheCodeTraveler]

This PR adds the Run Benchmarks step to the GitHub Actions CI/CD Workflow.

Additional Information
This PR also adds the following housekeeping updates to the GitHub Actions CI/CD Workflow:

• actions/setup-dotnet
  • Update to v4
  • Add dotnet-quality: 'ga'
    • This ensures the build step does not install a preview version of .NET
• Install .NET MAUI Workload
  • Add dotnet workload update following dotnet workload install maui
    • This is a workaround I've found to ensure pre-installed .NET workloads on the hosted agent are up-to-date
    • It's helped us fix CI/CD errors in the past
• Set Xcode version
  • Print the installed version of Xcode
    • This helps us identify when new versions of Xcode are supported in the hosted agents
    • This also helps us understand if this step fails when a hosted agent is running an old version of macOS that does not yet include the needed version of Xcode
• build_library
  • Add env: VSTEST_TESTHOST_SHUTDOWN_TIMEOUT: 1100
    • This fixes "The active test run was aborted. Reason: Test host process crashed "
• Build each project individually
  • Yes, it's redundant since dotnet pack first builds the csproj file, however, building each project individually makes it easier for us to quickly identify which project is throwing a compiler error and whether the error is occurring on dotnet build step or on dotnet pack

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

[VladislavAntonyuk]

Do we have this issue on new pipeline?
I also curious if this variable is specific to Azure Pipelines or exists in Github.

[TheCodeTraveler]

Haha - I wish I knew the answer to that!

I don't have direct evidence that supports whether we still need it in GitHub Actions or not, but I'd kinda rather keep it just in case since it doesn't introduce any adverse effects to the pipeline and it may save us headaches in the future.

[VladislavAntonyuk]

this should be a library, not solution

[TheCodeTraveler]

I used the Library SLN on purpose to help ensure the pipeline always builds all of the projects.

In the future, a PR may add a new library but forget to update the pipeline. This ensures that the pipeline will still compile the new code until we remember to add it as a separate step.

[VladislavAntonyuk]

Sorry, in that case I still don't see the benefit of building each project individually to build the whole solution later.
I have no strong objections merging the PR, but I still voting keeping it as simple as possible (less code). Once we get the issue with build investigation we can back to the changes.