[ALL] Add the ability to override weapon slot and position, with very basic TF2 UI support

[FlaminSarge]

Description

This PR adds the ability for vscript/mods/etc. to override the slot and position in which a weapon will appear in a player's weapon selection HUD for all games. It does this by adding m_iSlot and m_iPosition as networked properties on CBaseCombatWeapon, which are initialized to the values previously returned by GetSlot() and GetPosition(). These two methods now return those properties (and have been moved to be inlined in the header file; this can be reverted if needed). It also makes m_iSubType networked so that multiple weapons of the same class can be used by one player without any conflicts with SelectItem() behavior, if the vscript/mod so desires (lack of networking meant that overriding this during runtime would result in the client attempting to call SelectItem() on a subtype that may have desynced from server).

This PR also updates the TF2 weapon selection HUD to display the currently-selected weapon for the active slot if there are more than one weapon in that position, as well as updating the implementation for the TF2 Plus-type fastswitch HUD so that it can function even with multiple weapons in one slot. This includes a fix where slot5/slot6 inputs would cause the Plus-type HUD to function incorrectly.

If vscript/etc. do not touch these properties, all behavior remains the same as stock for all games.

~~Note that due to tf_weapon_builder's unique setup, it is not affected by these changes (yet).~~ tf_weapon_builder's slot/pos netprops are updated whenever SetSubType() is called on it but otherwise function as other weapons do.

Demonstration: TF2: https://youtu.be/glJDdKqSIrU HL2DM: https://youtu.be/XsAfBYtv54w

Includes the changes in #901

[FlaminSarge]

The intent behind this PR is to provide base functionality with semi-functional UI for VScript to start working with in the base (live) game. Attributes were considered instead of properties, but then HL2 wouldn't gain the benefit of these changes and there would be undefined behavior if the attributes were added to player instead of to weapon.

Because GetSlot() and GetPosition() are strictly used for clientside weapon HUD selection, these new properties shouldn't break demos, as far as I can tell.

The followup change to fully implement a custom UI for extra weapon positions is a longer-term goal that may or may not be viable to merge into live game. I mainly plan to make it available for TF2 community mods to pull in, currently WIP at https://github.com/FlaminSarge/source-sdk-2013/tree/buckets, but if it's something that merges cleanly into base game, all the better.

[gidi30]

This looks really good! However it seems to be missing some code in CTFClientScoreBoardDialog and CTFHudPlayerClass to make it show the correct weapon model depending on whats equipped and not just the first weapon in the slot

[FlaminSarge]

@gidi30 is that for the 3D player model in HUD? Good catch.

[FlaminSarge]

This looks really good! However it seems to be missing some code in CTFClientScoreBoardDialog and CTFHudPlayerClass to make it show the correct weapon model depending on whats equipped and not just the first weapon in the slot

On second thought, their usage of GetLoadoutSlot seems extremely deliberate for both cases:

int nItemSlot = ( pPlayer->IsAlive() && pPlayer->GetActiveTFWeapon() ) ? pPlayer->GetActiveTFWeapon()->GetAttributeContainer()->GetItem()->GetStaticData()->GetLoadoutSlot( nClass ) : LOADOUT_POSITION_PRIMARY;
...
	int nLoadoutSlot = pPlayer->GetActiveTFWeapon() ? pPlayer->GetActiveTFWeapon()->GetAttributeContainer()->GetItem()->GetStaticData()->GetLoadoutSlot( m_nClass ) : LOADOUT_POSITION_PRIMARY;

While I could replace this with just getting the active weapon, I'd like to find out the intent behind them sticking to loadout slots instead of just using the active weapon there...

I have put up a basic implementation at https://github.com/FlaminSarge/source-sdk-2013/compare/bucket-prop...FlaminSarge:source-sdk-2013:bucket-playermodels but I do not think it is a very good implementation.

[FlaminSarge]

~~Noticing that for singleplayer purposes this may need to add some handling for the 3 props in save data, looking to add that now.~~ This seems to be handled properly already via the addition to the datadesc.