Implement a generic "find items in player possession that match a criterion" function. [WIP] [CR]

Currently there are several functions in the player / inventory class that iterator through all the items the player currently has (worn+inventory+weapon) and check for a criterion and return the matching items. Those functions have been duplicated (and slightly changed for a new criterion) several times.

The generic functions (two version of it for different usage) takes a filter object.
This object controls what items the function should return.

The generic functions have several advantages:
- No more clutter of the player / inventory class with functions that are used once. For example `player::has_drink` or `inventory::all_drinks` are used once in iexamine.cpp. If one needs to search for specific items, just write a filter and apply that filter, no need to add functions visible to everyone.
- A simple function that looks for items in the inventory *and* in the weapon slot *and* in the worn list. No more additional check for the weapon slot (see the usage of  `inventory::all_drinks`, the weapon was added separately if it matched).
- In case the weapon or the worn vector get moved / included in the inventory or the inventory system changes, only the generic search functions need update. The filter and the code that uses the search functions remain unchanged. Similar when one wants to change what is searched for, that is only defined at once place, the filter struct.
- Better filtering. Instead of coping the existing functions, one can simply write another filter struct and add as much filtering good as one needs. Because the filter itself is usually not visible anywhere else, making it as specific as possible does not matter. One filter checks for is_drink, another for is_drink, but not alcohol, another for is_drink with alcohol etc. Any additional exceptions can be included there. That would normally require 3 separate functions in player *and* again in inventory.
- Less code dependency. The player / inventory class don't need to know the data that the filter uses. If `iexamine::aggie_plant` needs (in the future, who knows) fertilizer with special properties for a specific plant, that can be added without changing code elsewhere (especially not in the inventory or player class).
- Less code duplication. For example in iexamine.cpp when planting a seed, the function uses `inventory::all_items_with_flag`, but than it additionally looks whether the weapon matches and adds it. Similar some functionality is implemented as `has_foo` (checks for existence of an item with property foo) and `get_foo` - (gathers all items with property foo). Instead the `has_foo` can be implemented as `!get_foo().empty()` (are there *any* items that match the filter). This also avoids potential errors like `has_foo` using a *slightly* different meaning of foo than `get_foo`, or it looks at different items (`has_foo` includes the worn items, `get_foo` might not).

----

Similar generic functions can be used for other iterations, e.g. looking for items with light emission or ...

There is a *lot* of iterations of that kind in the inventory and the player class.

Finally this reduces the direct usage of `player::inv`, `player::worn` and `player::weapon`. That should make it easier to reduce their visibility to protected or to move them into the Character class. The caller however must use functions like `player::use_charges` instead of `u.inv.use_charges`.

I implemented one function with a lambda construct, but I don't know whether this works with all supported compilers. It avoids creating another struct that's used only once.

----

I changed the some function to use the new functions to show how it could look like.

Is there any interest in that?

Any suggestions for better naming of the functions?
It's a template function, if you put it into a cpp file, you have to put the filter class in a header, too.

If you put this into player.cpp, you need to make all the filter classes visible in a header, which player.cpp would have to include. Than you need to instantiate this function for each filter function inside of player.cpp. That creates way more dependencies. Adding a filter would need to change player.cpp and add code to a header somewhere else, needing to recompile at least two files (player.cpp and the other file where you use the filter).

By putting this function into a header (but not any of the filter functions).