[Ready] Item access refactor

See #9517
If someone could enlighten me as to what these necessary hooks are, that'd be great.  As it is there is still no justification for this.
If all you need is a way to expose a list of modifiable items without exposing the list itself, just return a list of pointers to the items.  The pointers won't be stable across insertion/removal, but they will be stable across item modification.
Once you have that, all we need to do is add an
```item map::remove_item(int x, int y, int index);```
method and I think you have everything you're looking for.
That's simple and clean enough that additional justification for the infrastructure is unnecessary.

Re Your example: Wouldn't the hooks go into the thing being modified, the item?  It makes perfect sense to have:
```
item::modify_brightness( int newval, bool onmap ) {
    if( onmap && newval != brightness ) {
        g->m.invalidate_lightmap();
    }
}
```
But that belongs in the item, because the item knows about it's brightness property, but it does inform callers that it needs to know whether it's on the map or not when its brightness is changed.
(this has the caveat that nothing should be modifying item brightness like this)