Controller backend improvements

[RetroEdit]

Fixes #4550

Check if completed:

• I have run any relevant test suites
  • Also, spot-tested on GB and NES
• I, the commit author, have read the licensing terms for contributors (last updated 2024-06-22) and am compliant

[SuuperW]

Bk2Controller.Bk2ControllerDefinition.GenOrderedControls is also incorrect. The base implementation remarks that other implementers should include empty lists for groups with no buttons. It seems like the only reason that empty lists should be included is that there's special logic expecting console buttons to be in the first group. (e.g. for NES, the power button is in group 0, player 1's buttons are in group 1) But this implementation removes empty lists.

Related, Bk2LogEntryGenerator.GenerateLogKey also removes empty lists.

Removing empty lists in these places probably solved some issues that were created by reporting PlayerCount of 1 for handhelds and then assuming there are PlayerCount + 1 groups, which this PR fixes.

This removal of empty lists should only be a problem if there are any cores that have no console buttons and have multiple controllers. In that case, input display will show player 1's inputs last in the list of inputs instead of first. I do not know if there are any cores like this, but I think these implementations should be fixed regardless.

And it might be a good idea for this PR to change the public NumControllerGroups to return ControlsOrdered.Count instead of re-calculating it. It seems like these two values should always match. (The use of NumControllerGroups inside GenOrderedControls would need to be updated.)

[RetroEdit]

One wonders if NumControllerGroups should even exist if it's just wrapping the public ControlsOrdered.Count...

While I agree Bk2Controller doesn't match the base implementation's specification in that comment, and I think you're probably right it would be okay and more correct to remove the empty entry filtering, I don't want to change more than necessary.

But if you feel strongly, feel free to add it to this PR (or make your own commit).

[SuuperW]

I think it's OK to leave it, since I doubt it's causing any issues.

I pushed some updates for macros. Merge conflict here should just be because MovieZone.cs was renamed.