FIX: Improvement for event handling in FixedUpdate mode

[AlexTyrer]

Description

Previously InputAction.WasPerformedThisFrame() could be true for consecutive frames.

This happens in frames where no FixedUpdate steps are run.

There is a semantic confusion here:

• WasPerformedThisFrame() was really checking against InputSystem UpdateStep (not frames)

Changes made

Adding a frame value to the TriggerState struct allows better checking in these InputAction APIs:

• WasPressedThisFrame()
• WasReleaseThisFrame()
• WasPerformedThisFrame()
• WasCompletedThisFrame()

Testing

Tested using the user supplied bug project.
Manual and automated tests.

Risk

I've increased the size of the TriggerState structure by 4 bytes.

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.