The universal-item-manager is a fairly powerful plugin to allow for control of weapons (and potentially many other entities as well) in L4D2. It could easily be expanded for other games. It's still a work in progress, so some things may (read: will) be a bit iffy!

Currently, these are its functionalities:

##ConVars: ###uim_force_exist_all uim_force_exist_all (def "1")
This cvar adds in the "must exist" flag for every _spawn item, in an attempt to cause them all to exist so the plugin had a bigger range of items and could make all the decisions on its own, rather than being pre-limited by the game itself. Sadly it doesn't seem to work at all!

##Commands: ###uim_limit uim_limit "item name" "limit inside start saferoom" "limit in the map (outside saferooms)" "limit inside end saferoom"

This is the basic command of the whole thing: it limits the number of items of name "item name" to the specified values in each region of the map. It adds tracking for items of that type, and considers that "item name" is the classname that will be looked for! From here there's 2 things that might be true:
a) "item name" is indeed the classname of the entity you want to remove, for example "weapon_pain_pills", in which case you probably don't need to do anything else.
b) "item name" is a mock name! For example "gascan", which is the name that you want to refer to the item by, but not the classname of the entities you aim to remove. For gascans that classname would be "prop_physics". In such cases you will have to specify the classname, and possibly other details to help identify the entities properly. For example, if you did this:
uim_limit gascan 0 0 0
uim_addrule specifier classname prop_physics //more info on this command below
You would be limiting an item type you call "gascan" to 0 everywhere. Since you specified the classname as prop_physics, it would remove all entities of that classname! Clearly you need more information to effectively remove gascans (and only gascans).

###uim_limit_createcvar uim_limit_createcvar "item name" "name of cvar for limit in stat saferoom" "name of cvar for limit in map" "name of cvar for limit in end saferoom"
This just creates a convar on the fly that you can use to change the limits. The reason for this is simple: we can't have everything be cvar'd since there's too much information and we want to allow for control of every possible entity, but at the same time cvars are handy if you want to scale it with another plugin, or just as a matter of personal preference, why not? If you don't want all 3 regions to be cvar'd: "@*", as in a @ followed by any other non-whitespace characters, will be ignored and not cvar'd. In addition, to differentiate between the regions, "s_", "m_" or "e_" are automatically prefixed to the name you provide! So this:
uim_limit_createcvar weapon_adrenaline cool @lol example
Would create a cvar named s_cool that controls the limit of adrenaline in the starting saferoom and a cvar named e_example which controls the limit of adrenaline in the end saferoom. Limit in map would not be cvar'd since the name provided for it starts with a @.

###uim_addrule uim_addrule "rule name" "item name" "extra information" "..."
This command lets you add rules so the plugin knows how to identify and handle different items that need extra details, like gascans.
The currently implemented rules are this:
####BAN uim_addrule ban "item name" "minflowpercent" "maxflowpercent"
Simply removes all items in ranges added with this command. For example if you don't want pills to spawn in the last 30% of the map, you could do this: uim_addrule ban weapon_pain_pills 70 100 ####KEYVALUE uim_addrule keyvalue "item name" "key" "value"
This specifies keyvalues to be dispatched to entities when they are spawned. This is necessary because the plugin removes all entities and then respawns them, and upon respawning some details may be necessary. The plugin will simply use DispatchKeyValue() for all of the added keyvalues for the entity, before spawning it. A common use is to set the model for a prop_physics for example! ####SPECIFIER uim_addrule specifier "item name" "specifier type" "extra info" "..."
Adds a 'specifier', which is just a bit of info that is checked to identify items correctly, as in the case of gascans which are 'prop_physics' and are obviously not the only 'prop_physics' entity in the game. #####CLASSNAME uim_addrule specifier "item name" classname "name"
Sets the classname for when you use an alias at first, like a #####PROP_DATA uim_addrule specifier "item name" prop_data "key" "value"
CURRENTLY ONLY WORKS FOR STRING PROPS, DO NOT USE FOR PROPERTIES THAT ARE NOT STRINGS.
Makes it so items of "item name" must have the "key" prop in prop_data set to "value".
For a decent example of how this can be useful, look at cfg/lgofnoc/lgofnoc_base_items.cfg on this repository. It's currently only used to specify the model of "item name", but can be used for other things. #####PROP_SEND uim_addrule specifier "item name" prop_send "key" "value"
CURRENTLY ONLY WORKS FOR STRING PROPS, DO NOT USE FOR PROPERTIES THAT ARE NOT STRINGS.
Makes it so items of "item name" must have the "key" prop in prop_send set to "value". Currently not used for anything in ProMod, but the logic is the same as Prop_Data specifiers, except for netprops.

IMPORTANT: Currently, you must use uim_limit for an item before adding specifiers or keyvalues for it!! uim_limit_createcvar probably also requires that, at the time of writing this I can't remember 100%.