fix next/prev weapon without carousel

[fabiangreffrath]

Fixes #2196

[ceski-1]

I'm not really familiar with g_nextweapon.c, so I'll ask some questions and share some results.

What is the traditional behavior for next/prev weapon when the automap is open? What is the desired behavior? What takes priority when the automap is open? Should the behavior differ for the overlay automap (because the weapons are visible)?

With this PR, here's how next/prev weapon behaves with the automap open:

• Keyboard Q/E keys: weapons cycle, no automap zooming
• Mouse4/Mouse5 buttons (side buttons): weapons cycle, no automap zooming
• Mousewheel up/down: automap zooms in/out, no weapon cycling
• Gamepad LB/RB buttons: weapons cycle, no automap zooming

[fabiangreffrath]

What is the traditional behavior for next/prev weapon when the automap is open?

Traditional ports, including MBF, did not have prev/next weapon bindings. Chocolate Doom allows to bind prev/next weapon to the mouse wheel, but does not allow to bind Automap zoom to any mouse button, so the events are passed through if the Automap is open.

What takes priority when the automap is open?

I think the Automap bindings should be given priority when the Automap is open.

Should the behavior differ for the overlay automap (because the weapons are visible)?

This would be surprising IMHO.

With this PR, here's how next/prev weapon behaves with the automap open:

* Keyboard Q/E keys: weapons cycle, no automap zooming

* Mouse4/Mouse5 buttons (side buttons): weapons cycle, no automap zooming

* Mousewheel up/down: automap zooms in/out, no weapon cycling

* Gamepad LB/RB buttons: weapons cycle, no automap zooming

Sounds reasonable to me (I assume Q/E and mouse side buttons are bound to prev/next weapon).

[ceski-1]

Should this be reset to false in G_NextWeaponReset?

[fabiangreffrath]

Most probably yes!