Update active items periodically instead of constantly.

The short version is this change lets the game spend up to 600 turns (1 hour) between rot checks for food, and up to 100 turns (10 minutes) between raise checks for zombies and similar.
There's also a fix in there for a bug where every comestible was being set to active, this pretty much wrecked my attempts to make this work properly, because all food everywhere was being added to the lists for processing, and worse, many of them were being added to the default "check every turn" list.

The longer version is that I split the active item list into a potentially arbitrary number of sub-lists, each of which guarantees only that the items on it will be processed at least once every n turns.  In reality we're only using three at the moment (with ns of 1, 100 and 600)
It does this by building a list of item references from its lists that contains the first list.size() /  n items rounded up and returning that list for processing.  When being processed, the items are removed from the lists and then pushed onto the back of the list, so after processing the items that were at the start of each list are now at the end of each list.

Another optimization is item_stack::push_back_fast(), if we know an item can and will fit in a square, such as if we just removed it while processing it, we can skip the checks imposed by map::add_item_or_charges and go straight to map::add_item.  The check for inserting items into vehicles isn't as expensive, so I didn't bother with it for now.

Fixes #9926 and should fix #10269
I'm not sure what you mean by use a pointer, my guess is you mean make active_item_set a ```std::unordered_set<item *>``` and insert into it with ```active_item_set.insert( &*it )```.
While that would work, I'm not sure what the benefit would be.  Let me know if I'm missing something.

By forwarding to the submap, I assume you mean adding setters/getters etc to the submap and making the actual container private?  That's the kind of thing I'm generally working toward, but I'm running out of time right now so I don't want to embark on another set of API changes in this PR unless it's totally necessary.