chore: Small yamato tweaks to try speed up our PR trigger runs

[EmandM]

Purpose of this PR

I've spent too much time staring at yamato over #3647 . Decided to see if we can tweak our PR trigger to be more efficient.

Jira ticket

n/a

Changelog

• Removed ::GPU from the agent.type for desktop_standalone_build, desktop_standalone_test and cmb_service_standalone_test. All of these jobs disable the GPU so they don't need a machine with a GPU (gpu machines are much rarer)
• Swapped the PR trigger to run desktop_standalone_test_testproject_ubuntu_il2cpp_trunk rather than desktop_standalone_test_testproject_win_il2cpp_6000.0 that way the desktop_standalone_test and the cmb_service_standalone_test can use the same desktop_standalone_build step rather than needing two different build steps
  • This does mean we no longer run PR tests on ubuntu_6000.0.
  • I think this is fine as mac and windows are by far the most used platforms.
  • We will still test ubuntu_6000.0 on the nightly and weekly builds.
• Defined a smaller_flavor field in test_platforms.desktop to use with lighter weight jobs (package_pack, package_tests, project_pack). I chose which jobs to use a smaller VM from looking at the machine usage stats on bokken (like I say, I stared at yamato TOO MUCH this week).
• Updated upm-ci to UnifiedTestRunner for the project_pack and project_test jobs.

Documentation

• No documentation changes or additions were necessary.

Testing & QA (How your changes can be verified during release Playtest)

No testing needed.

Functional Testing

Manual testing :

• Manual testing done

Automated tests:

• Covered by existing automated tests
• Covered by new automated tests

Does the change require QA team to:

• Review automated tests?
• Execute manual tests?
• Provide feedback about the PR?

If any boxes above are checked the QA team will be automatically added as a PR reviewer.

Backports

Backported by #3724

[michalChrobot]

@EmandM instead of leaving a comment I just pushed some small changes (see last commit) which were

1. Some comments clarifications
2. re-adding reruncount argument to all build-only jobs. In those cases no tests are being run so we can't use teststrategy + retry and I think we should leave this to rerun build attempt if it fails due to some "random" reasons