fix warning: use unity 6 api when compiling for unity 6

[ggStrider]

Thank you for sending a pull request! Please make sure you read the contribution guidelines

Pull request checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
• No compiler errors or warnings

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

Issue Number

Issue Number: N/A

What is the current behavior?

Using obsolete API in Unity 6 causes compiler warnings.

What is the new behavior?

When compiling with UNITY_6000 defined, the new Unity 6 API is used,
eliminating obsolete warnings while keeping compatibility with older Unity versions.

Does this introduce a breaking change?

• Yes
• No

Other information

This PR only adds a conditional compilation check to use the Unity 6 API.
No functional changes are introduced for other Unity versions.

On which Unity version has this been tested?

• 6000.0.58f2 LTS
• 2020.4 LTS
• 2020.3
• 2020.2
• 2020.1
• 2019.4 LTS
• 2019.3
• 2019.2
• 2019.1
• 2018.4 LTS

Scripting backend:

• Mono
• IL2CPP

[tigran-sargsyan-w]

Summary
Fixes Unity 6 compiler warnings by switching from FindObjectsOfType to the new FindObjectsByType API behind #if UNITY_6000 guards in ProjectContext.cs and UnityUtil.cs.

Strengths

• Minimal, targeted change; preserves behavior on older Unity versions.
• Correctly uses the FindObjectsByType<T>(FindObjectsSortMode.None) overload to avoid sorting overhead.
• Reduces noise from obsolete API warnings in 6000.x without altering runtime logic.

Suggestions

1. Preprocessor symbol
   Consider using UNITY_6000_0_OR_NEWER (or even UNITY_2023_1_OR_NEWER) if you want to enable the new API for earlier versions where FindObjectsByType already exists, and to be future-proof with Unity’s common _OR_NEWER convention.

2. Namespace clarity (minor)
   If there are files that also using System;, you could qualify Object as UnityEngine.Object for clarity (purely stylistic; not blocking).

3. Behavior parity note
   The old calls (FindObjectsOfType without parameters) return only active objects; the new calls here should match that. If any callers relied on inactive objects, consider the overload with FindObjectsInactive.Include. (Looks fine as-is for ProjectContext and the scene enumeration use-case.)
   looks good overall; the _OR_NEWER define would make it a bit more robust.