Make unit select and command rebindable

[burnhamrobertp]

Right now left-click always selects and right-click always commands - it's baked into the engine in a bunch of spots, so games can't move it to other buttons.

This makes select and command into regular bindable actions, mouseprimary and mousesecondary. They still default to mouse1/mouse3, but you can now bind them wherever - a spare button, a footpedal, or swapped. mouseprimary also confirms a picked-up command (placing a build, targeting a dgun); mousesecondary cancels one.

The defaults aren't hardcoded in C++ - they're normal binds shipped in config, so the game owns which button does what. That's the whole idea behind #377. BAR ships its own; companion PR: beyond-all-reason/Beyond-All-Reason#8329.

Heads-up on the history: this started as a smaller "let a bind win over the built-in" approach, then got reverted partway through (the "Drop the mouse-button MousePress override" commit) once it was clear the cleaner path was making the built-in behaviors themselves bind-driven - which is what you pointed at in review.

Implemented and tested with Claude Code, including the left/right swap in BAR.

[burnhamrobertp]

Previous review changes are no longer relevant; this branch takes a slightly different path by shifting the LMB and RMB bindings to be managed through LUA since there's no requirement for native actions

[burnhamrobertp]

@sprunk the scope of this has changed, driven by the points you had made; not necessarily smaller, I don't think, but better aimed.

If you want to test it in combination with BAR changes, beyond-all-reason/Beyond-All-Reason#8329 should work well

[sprunk]

So what about the issue where RMB bindings never fire because some input receiver has priority?

[burnhamrobertp]

So what about the issue where RMB bindings never fire because some input receiver has priority?

This is the same behavior that we see with any other input event, correct? If one binding has higher priority and returns true (stopping propogation of the input event) then other actions bound to that same input won't fire. This consistency is good; and if the issue is that the engine allowing conflicting bindings that create these circumstances in the first place, then it can be solved across all circumstances with the same consistency.

If the scope of this is large enough that it needs to be addressed in this work, I can look into that; it just seemed like a totally separate problem to me, warranting its own PR.