CHANGE: Refactor class conditional guards

[jdiehlUnity]

Description

Moves around some conditional guards so that we don't unnecessarily wrap entire classes. This stops downstream packages from having to also wrap Input System objects with similar conditionals.

Only device class definitions that get replaced by specific packages should be entirely wrapped.

This PR is a copy of the internal PR created here: https://github.cds.internal.unity3d.com/unity/com.unity.inputsystem/pull/5

Changes made

Removes #if UNITY_INPUT_SYSTEM_ENABLE_XR && (ENABLE_VR || UNITY_GAMECORE) && !PACKAGE_DOCS_GENERATION
guards from wrapping entire class files under InputSystem/Plugins/XR/Devices and InputSystem/Plugins/XR/Haptics.
This makes it so any packages that want to use these Input System package objects don't have to also wrap the use of those objects with #if ENABLE_VR guards. Classes that should ignore Package Generation have been added to the filter.yml file.

We now only wrap the use of device descriptors with #if UNITY_INPUT_SYSTEM_ENABLE_XR to prevent use when the XR Module package is not installed.

Testing status & QA

Engines Supported: 6.2, 6.1, 6.0, 2022.3, 2021.3

Test 1:

• Create project (or use an existing one)

• Install Input System package

• Install OpenXR package (this package uses the Input System but currently does not wrap any objects).

• Switch platform from Standalone or Android into tvOS or QNX (ENABLE_VR conditional wont be defined on these platforms)

  Expected result: No compiler errors

Test 2:

• Create project (or use an existing one)

• Install Input System package.

• Install the com.unity.xr.oculus, com.unity.xr.openvr, and com.unity.xr.windowsmr packages (these packages override certain device class definitions).

  Expected result: No compiler errors

Test 3:

• Create project (or use an existing one)

• Install Input System package.

• Implement something that tries to leverage an XRHMD or XRController object

• Switch platform to tvOS or QNX (ENABLE_VR conditional wont be defined on these platforms)

• Execute code in Editor or in a build for the new platform.

  Expected result: No runtime errors

Overall Product Risks

Please rate the potential complexity and halo effect from low to high for the reviewers. Note down potential risks to specific Editor branches if any.

• Complexity:
• Halo Effect:

Comments to reviewers

Please describe any additional information such as what to focus on, or historical info for the reviewers.

Checklist

Before review:

• Changelog entry added.
  • Explains the change in Changed, Fixed, Added sections.
  • For API change contains an example snippet and/or migration example.
  • JIRA ticket linked, example (case %%). If it is a private issue, just add the case ID without a link.
  • Jira port for the next release set as "Resolved".
• Tests added/changed, if applicable.
  • Functional tests Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
  • Performance tests.
  • Integration tests.
• Docs for new/changed API's.
  • Xmldoc cross references are set correctly.
  • Added explanation how the API works.
  • Usage code examples added.
  • The manual is updated, if needed.

During merge:

• Commit message for squash-merge is prefixed with one of the list:
  • NEW: ___.
  • FIX: ___.
  • DOCS: ___.
  • CHANGE: ___.
  • RELEASE: 1.1.0-preview.3.

After merge:

• Create forward/backward port if needed. If you are blocked from creating a forward port now please add a task to ISX-1444.

[unity-cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[surfnerd]

Approved the internal PR, approving this based on my review there. See link in description for discussion.