CHANGE: Input type registration via Roslyn source generator to reduce use of Reflection

[ekcoh]

Description

This PR evaluates the approach of relying on Roslyn source generators to generate code for auto-registration of extendible Input System types. Existing auto-registration code has been raised as problematic since it drives memory usage and generates run-time overhead.

Completed issues:

• Add a Roslyn source generators to Input System that detect and generate source code to register interaction, processor and binding composite type registrations for user-defined types.
• Make sure Roslyn source generators have automated-test coverage to avoid regressions or unexpected behaviour.
• Document how to build and test the source generator project.

Open issues:

• Change how Project-wide Input Actions are enabled so that manual or automatic registration can happen from user-code to enable custom types in Project-wide Input Action assets.
• Add an analyser and add a diagnostic warning message that suggests to users that implicit automatic registration is deprecated and will be removed in a future version. Provide suggestion to explicitly allow auto-registration via tag types. This converts source generated registration into an optional opt-in without directly breaking this behaviour which allows users to migrate. This way both manual (recommended) and auto-registration can work in parallel with minimal overhead when tag types aren't used.
• A/B test differences to compile time and/or memory usage.

Testing status & QA

Please describe the testing already done by you and what testing you request/recommend QA to execute. If you used or created any testing project please link them here too for QA.

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.