Items without valid material are not flammable.

player::consume use the same logic to determine whether the consumed item is suitable for the batteries bionic.
bionic: add a message when activating a bionic is not done because of insufficient power.
Move some common crafting/construction requirements into a separate struct

The new struct is named requirements and is located in a separate file, construction and recipe inherit from it.

The tool qualities has been moved there, too. The map of known qualities is now stored in a static map inside the quality struct.
Some functions for loading, consistency checking and listing of missing things has been moved into the requirements struct.

This does not yet introduce new feature, but allows constructions to load item qualities.
The member id of quality_requirement has been renamed to type to be consistent with the member of struct component.
As the quality related functions are now part of the quality class, the string "_quality" has been removed from their names as it is redundant.
Move the printing of required tools / components into requirements

Use fold_and_print instead of manually doing this.
Combine special case for the mutation WEB_ROPE and bionic bio_sunglasses for construction and crafting.
Made itype::count_by_charges const, because that's what it should be and it allows to use only a const itype in the requirements.
Move crafting/construction time to requirement class.

Now constructions use the same time scale as crafting, but this is ported to json.
The construction time is converted when loaded from json.
Enhanced the time display to display hours and minutes or seconds (if less than a minute).
Move game::can_make_with_inventory and game::check_enough_materials to requirements class

This allows to use the same logic to check for tools/qualities/components in recipes and in constructions.
This enables tool qualities in constructions.
Harness the power of templates:

Made the three lists of required things in requirements (tools/items/qualities) to equivalent structures (vector of vector of something).
Used template functions to iterate over these lists (with template parameter being that something - tool_comp/item_comp/quality_requirement).

Moved whatever differs into those structures:
- color to be displayed in the the list of requirements - red for not available, gray for other item can be used, green for available, other colors for specials (mutations).
- the name of the something ("welder (40 charges)"/"3 rocks"/"4 tools with sawing quality level 5")
- loading from json (quality uses an json object, tool has simpler format in constructions)
- check for availability (checks mutations, other specials)
- consistency (quality has a different check than item type)