Remove optional maxitems from map::add_item{,_at}

It turns out the parameter wasn't really being useful anymore. It's an artifact from when the `add_item_at` code would actually perform item overflow itself -- later, that got moved up into map `add_item_or_charges`, but the parameter was kept... with a simple "return;" in place of the overflow code.

Ordinarily, this wouldn't be a problem -- the only way to call into `map::add_item` was from `map` itself, namely from `map::add_item_or_charges`. Which checked for overflow and didn't even call into `add_item` if it would enter that code path.

However, recently, `map::add_item` got made public (#10293) so it could be used to bypass terrain flag checks (specifically, the `NOITEM` checks that would cause items to spill over into adjacent tiles.  Remember gas pumps with their fuel next to them?  Yeah, that bug). When the new calls to `add_item` were added, they omitted the optional parameter, so the code defaulted to... 64.

This was _still_ not a problem! Most functions using this were doing it in mapgen, where the aforementioned fuel was placed onto the aforementioned gas pump, or similar places --  there would only ever *be* one (or, very rarely, two) items in the given tile. The evil bug would still not be activated until...

...active item processing needed a faster way to insert items back into the map (#10599). So it used `map::add_item_at`, because that's _nice and quick_. It makes perfect sense, too: there's no need to check most potential issues with dropping items into the given tile because we _got_ the items from that tile -- ergo, they are supposed to be there.

BUT:

- because the default maxitems was 64,
- whenever a tile had more than 64 items in it,
- any active items in that tile would get pulled out for processing...
- ...and attempt to insert back in, **which would silently fail**, destroying the item.