Try to fix multiple container-in-shop bugs; it seemed as if every time
I tried to investigate one I stumbled into another. billable() (post-3.4.3
code, but already present in branch as well as trunk) didn't handle
containers properly. It sometimes gave the wrong answer and it didn't
clear the no_charge flag of contained items as the old code in addtobill()
it replaced did. stolen_value() didn't use the actual bill price for an
item already on the shop bill; it generated a new price which might be
different if the object was unID'd (3.4.3 had this one). Throwing didn't
handle a container owned by the hero which contained items owned by the
shopkeeper. I'm still not quite sure what's going on there, but throwing
the container out of the shop didn't give any feedback but did add to shop
charges which don't show up in ``I x'' (but do get revealed by ``$'' or
``I $''). (This was intertwined with some of the other stuff and I don't
know how 3.4.3 behaved in this regard. Now there's some shop feedback for
the throw and the contents show up for ``I x''.) An unpaid container which
contained another nonempty unpaid container showed a different price when
picked up and in inventory display [k - a bag (unpaid, NNN zorkmids)]
compared to what was on the bill and showed by ``I u'' because the first
two included double billing of the nested container (just it, not its own
contents). [There where a few recursive calls of the form
x += func(x)
which should have been either
x = func(x)
or x += func(0).] Purchasing used the right amount, I think. I'm not
sure whether 3.4.3 had this particular bug or whether fixes for some of its
other container bugs inadvertently caused this one.
This patch also changes stolen_container() to work like the other
recursive shop routines: it just handles the contents, leaving the outer
container itself to be handled by its caller. It seemed inconsistent, and
changing it simplified the fix for using bill price on stolen unpaid items.