Check json item definitions consistency

[BevapDin]

This adds some checks for consistent item type definitions and references, (only done with --verifyjson).
If a check fails, a debug message is printed.

Checks that components/tools & result of recipes refer to existing item types in item_controller (prevents the "char_smoke" in #4680).

Same for each item in each item group (prevents things like #4683, #4567).

Checks that it_ammo::casing, it_tool::reverts_to, it_comest::tool, it_comest::container are defined item types (or "NULL" / "null") - (prevents things like #3721, #3360).

Checks various ammo references - they should be listed in ammo_name() and checks that at least one item type of this ammo exists. This is skipped for tools with no max_charges (folding bicycle uses ammo "none", most other tools use "NULL").

Checks that item material (m1, m2) refer to known materials.
material_type::find_material will return a NULL pointer on invalid materials, can be seen when a sealed 3l-jar of kompot (or any mutagen) is put into an acid pool - will cause a segfault ("Tried to get invalid material: ..."). This can easily happen: a zombie dies and drops jar_kompot, a spitter creates an acid pool.

As a fix for the material bug: changed the material for mutagens from "NULL" to "null", as this is the material id used in materials.json.

jar_kompot has material "water", pudding & yoghurt have material "milk" - both materials are not listed in materials.json - this will trigger the same bug as above. Therefor material_type::find_material returns now a pointer to a null material instead of a null pointer.

[narc0tiq]

Note that --jsonverify was a great big security hole for Jenkins because of how it worked -- it effectively meant anyone could execute arbitrary code as part of the make process, which executed automatically for every single new commit to any pull request. It has been replaced with a separate executable named chkjson, which only depends on its own source and json.cpp.

As a result, any changes outside of json.cpp or chkjson.cpp will not be automatically executed during the build process. Furthermore, introducing any extra dependencies to chkjson.cpp will make the attack surface that much larger and would almost certainly be a bad idea.

I will not allow anyone who comes along to blow away the Jenkins just because he's feeling a little clever today and "wants to see what will happen".

[BevapDin]

Sorry for that, I thought that the --jsonverify would only be called manually as a help for modders. These functions were intended to be run separate and only on explicit invocation.
I'm really sorry if that caused any trouble. I'll better delete this than.

[kevingranade]

We very much want these checks, but maybe hooked up to a new flag if having
jenkins run them is problematic. I was hoping we could run a set of json
tests on pr because so many of them are json only changes now.
Could we have a known good exe run on the new json? Eg the latest mainline
build?
Regardless, I'd like any json consistency checks to run at startup on all
debug builds by default, and release builds too as long as they don't take
too long.

[narc0tiq]

@BevapDin -- The consistency checks are good, and as I explained, the Jenkins job is not using --jsonverify anymore; the rest of that comment was context, for clarity about why it would be a bad idea for it to do so, and was only tangential to the subject here.

@kevingranade -- using known-good source is what we need to be doing, yes; and I agree consistency checks would be wonderful to have on every single JSON-changing PR, for obvious reasons.

I'm gonna hit "Reopen" here. It was never my intent to discourage obviously good automated checks from being included.