feat: introduce configurable weapon catalogs

[DevD4v3]

Summary

This PR introduces configurable weapon catalogs and refactors the weapon module to support different gameplay styles without modifying consumer code.

The previous implementation relied on a static GtaWeapons collection that exposed all available weapons globally. While simple, it made it difficult to restrict weapon availability or support alternative weapon sets.

Changes

Weapon catalogs

Introduced a catalog-based architecture:

• WalkingWeaponCatalog
• RunWeaponCatalog
• MixedWeaponCatalog

Each catalog defines the weapons available for a specific gameplay style.

Weapon definitions

Introduced WeaponDefinitions as the canonical source of weapon definitions.

Weapon metadata such as slots are now defined in a single place and reused across catalogs.

Weapon catalog abstraction

Introduced:

• WeaponCatalogBase
• WeaponCatalog
• WeaponCatalogSettings
• WeaponCatalogType

The active catalog can now be selected through configuration.

Example:

# Available values: Walking, Run, Mixed.
WeaponCatalog__Type=Run

Dependency injection

Weapon catalogs are registered through the DI container and resolved dynamically based on the configured catalog type.

This removes the need for a global static weapon collection while keeping the public API simple for consumers.

Weapon pack

WeaponPack no longer relies on implicit default weapons.

New weapon packs start empty and are populated through the existing weapon selection flow.

This prevents inconsistencies when changing the active weapon catalog.

Architectural decisions

Why replace GtaWeapons?

The previous design assumed a single global weapon collection.

Introducing catalogs allows the server to restrict available weapons depending on the selected gameplay style while preserving a consistent API.

Why keep WeaponDefinitions?

Weapon definitions contain shared metadata such as weapon slots.

Keeping these definitions centralized avoids duplication across catalogs and ensures consistency.

Why start WeaponPack empty?

Weapon packs represent player-selected weapons.

Since players already select their weapons through the weapon selection dialog, pre-populating weapon packs introduces unnecessary state and can lead to inconsistencies when the active catalog changes.

For example, if a player's weapon pack contains a weapon that is not available in the currently selected catalog, catalog lookup operations such as GetById() or GetByName() may fail because the weapon can no longer be resolved through the active catalog.

Testing

• Updated weapon-related tests to use the new catalog architecture.
• Added validation tests for WeaponCatalogSettings.
• Simplified WeaponPack tests by removing assumptions about default weapons.
• Added tests for catalog lookup behavior through WeaponCatalogBase.