Throw debugmsg when setting charges for items that cannot have charges

[RenechCDDA]

Summary

Bugfixes "Butchery properly gives a scaling amount of butchery refuse, instead of just 1"

Purpose of change

@GuardianDll raised a question in the development discord about butchery only giving 1 butchery refuse. Some checks later, I found out that constructor naively sets charges regardless of whether the type is allowed to have them or not. This results in an item with a charges defined, but that is handled by our code as not being count_by_charges(), thus ignoring the value.

Describe the solution

Only set charges if type is allowed to have charges
Debugmsg if type is not allowed to have charges

Fix existing butchery call

Describe alternatives you've considered

Testing

Additional context

"Charges are the devil" -kevingranade

[RenechCDDA]

Oh yeah, the tests absolutely explode.

We have deeper problems than just butchery, don't we?

[mqrause]

Chances are 99%+ of those errors set charges to 1. Because any value bigger than that should trigger charge removal after a save/load cycle, causing stuff to fall out once you interact with it. And I'd expect that would have been noticed already.

[RenechCDDA]

Yeah that's what I'm seeing when running the tests locally, just lots of calls to the constructor with irrelevant quantities. I think I'm just going to paper over it by only throwing error on qty > 1

[mqrause]

Chances are also good this is coming from limited sources like item group creation.

[RenechCDDA]

Assuming this pass succeeds on GH I am going to consider removing the if qty > 1 requirement and eliminating the rest of the malcontents.

[PatrikLundell]

If there are too many complaints I'd suggest checking for >1 as suggested and then initiate a series of cleanup PRs, ending with the removal of the incorrectness hiding check. Especially in the light of the recent "too large" PR rules.

[akrieger]

IDK seems green.