more chest->tknown handling

Disarming a chest trap was setting obj->tknown = 0 even though the
hero just discovered that it isn't trapped.

Triggering a chest trap behaved similarly.  Since there are no
repeating chest traps, hero should know that the chest whose trap
just went off is no longer trapped.

chest_trap() didn't document its return value but was clearly meant
to return True if the chest was destroyed.  It didn't handle that
correctly when the chest was being carried.  However, none of the
callers actually use the return value.  [This fix tracks whether the
chest gets deleted; a better fix would be to destroy an exploding
chest even when it is being carried.]

doc/fixes3-7-0.txt

@@ -2100,6 +2100,9 @@ having a 1% chance of creating rideable monsters with worn saddle gave knights
 	tracked with other objects so produced a trivial memory leak
 when attacking a displacer beast, using the 'F' forcefight prefix prevented it
 	from swapping places with the hero
+successfully disarming a chest trap was clearing the chest's 'tknown' bit
+	instead of setting it; likewise when failing to disarm triggered and
+	used up the trap
 
 
 Fixes to 3.7.0-x Platform and/or Interface Problems Exposed Via git Repository