fix #H6960 - redundant feedback for '#force'

When using #force at a spot which has a broken or unlocked chest (or
large box) whose lock state has been previously discovered, avoid
|There is a broken chest here, but its lock is already broken.
|There is an unlocked chest here, but its lock is already unlocked.
by suppressing "broken"/"unlocked" from the chest description for
that particular message.

We might still want to change "broken chest" to "damaged chest" but
I don't think there should be any reference to its lock as the reason
it's broken or damaged.  The fact that #loot, #force, and applying a
key still treat it as a container is sufficient to reveal that it
functions as one.

doc/fixes36.1

@@ -527,6 +527,9 @@ fix 'object lost' panic if hero with lycanthropy but in human form is wielding
 prevent segfault if pline() is called recursively (which could happen if the
 	interface code issues a debugpline() while processing putstr())
 open at yourself is the same as #loot
+when #force reports that a chest's lock is already broken or already unlocked,
+	force it to be described as "a chest", even when its lock state is
+	already known, rather than as "a broken chest" or "an unlocked chest"
 
 
 Fixes to Post-3.6.0 Problems that Were Exposed Via git Repository