Show the recipes you know how to craft using an item as part of the item description [WIP/CR]

I also ended up yanking some of the crafting stuff out of game and putting it in player, where it made slightly more sense.

This is currently pretty slow… not sure how much can be done about that, but as it only does it when you look at the description for an item perhaps it doesn't matter too much?

It only displays for components, not tools. Recipes you can currently craft are highlighted.

I tried caching the recipe lookup but it turns out the slow part is checking recipe craftability.
> That method isn't actually part of the recipe class, it's part of the requirements class, which is inherited by recipe.

And therefor the function is implicitly part of the recipe class as are all the members of the requirements class.

> The comment's to make the line stand out more. It loads some major parts of the recipe, but is hidden at the bottom of the function.

Than put `// ############################` there, that stands out. But a comment that actually repeats what the code already tells (word by word!) is pointless and actually dangerous as it can easily become outdated. You can write `rec->requirements::load(jsobj);`, (here) it's the same as `rec->load(jsobj)`.

The new comment is basically the same as the documentation of that function in requirements.h, and it does not include the fact that difficulty, time and batch time factors are loaded there, too (also missing in the functions documentation). That's exactly what I meant with "becomes outdated". When someone extends the load function, where (if at all) will they add the proper documentation? Certainly not where the function is called.

And just to clarify: I'm not opposed to comments there (or anywhere), but they should be useful and therefor contain information about how or why it's done. This PR is fine, the changes are very reasonable, I just can't stand pointless comments.

Btw, if you put stuff like the loop to "add to reverse requirements lookup for each component" into a function, you can name that function aptly (e.g. "add_reverse_lookup") and avoid the comment all together (the function name descries what is done).

----

In the spirit of inheritance, it should probably work like this (requires some overhaul, no priority):
- recipe has a default constructor without parameters, but it has a load function.
- `recipe::load` loads the recipe specific stuff and calls `requirements::load`.
- loading the recipe is now `auto rec = new recipe(); rec->load(jsobj);`.
- than the loaded recipe is put into the recipe map.

Alternatively, one could remove the inheritance and make the requirements a member of the recipe / construction classes. Than it would be loaded as `rec->requirements_data.load(jsobj);` (or whatever the member is named). Actually this seems better than inheriting from requirements. Recipes and constructions *have* requirements, but they are not *some type of requirements*.

----

Unrelated note: storing the recipe pointer in the reverse lookup map when loading it, is potential unsafe. The recipe might be re-defined by a mod, the old recipe is deleted than and the pointer you have stored becomes invalid (see `check_recipe_ident`).