eating 1 of N floor tins in shop

Reported directly to devteam, eating 1 of 2 tins of spinach from a
shop's floor forced the hero to buy both.  (1 was gone, the other was
intact and now owned by the hero rather than the shop.  Tins of other
contents behaved similarly.)  The bug is easy to fix but not so easy
to explain:  eating split one from the stack but passed the remaining
stack to useupf(obj,1) which also split one off and treated that as
used up.  The second one was billed as used up and the first one was
added to the bill--as being subjected to a costly modification made by
the hero--and kept intact, now marked no-charge with hero obligated to
pay for it.

Eating 1 of N tins, for N greater than 2, billed for two, one gone and
the other now in a separate stack and marked no-charge.  The remaining
N-2 stayed as normal shop goods in their original stack.

The fix is communicate the splitobj() for costly modification up-call
so that the use_up_tin code operates on the one which was split off
the stack rather than on the remainder of the original stack.

doc/fixes36.1

@@ -404,6 +404,7 @@ fix the 'A' command to have the 'D' command's fix for C331-1 (quirk for
 	menustyle:Combination; if user included 'a' in "which object classes?"
 	response, to operate on applicable all items, there would still be a
 	followup menu asking to choose specific items)
+eating 1 tin from stack of N (for N >= 2) on shop's floor forced hero to buy 2
 
 
 Fixes to Post-3.6.0 Problems that Were Exposed Via git Repository