fix "bad fruit #0"

When minimal_xname() set up a dummy object containing as few details
as possible, it wasn't setting up the fruit id field, so xname()
couldn't figure out what type of fruit it had and issued a warning.

I haven't managed a test case that uses minimal_xname so testing of
the fix is less than comprehensive.  [Pasi got it through dopay, but
that only resorts to minimal_xname if the formatted name is really
long and would otherwise cause the shopkeeper's prompt to overflow.
Long fruit name combined with long individual object name wasn't
long enough to trigger that.  Maybe uncursed, greased, rustproof
the like, or possibly just a longer shopkeeper name than I had?]

src/objnam.c

@@ -1,4 +1,4 @@
-/* NetHack 3.5	objnam.c	$NHDT-Date: 1426470349 2015/03/16 01:45:49 $  $NHDT-Branch: derek-farming $:$NHDT-Revision: 1.108 $ */
+/* NetHack 3.5	objnam.c	$NHDT-Date: 1429413519 2015/04/19 03:18:39 $  $NHDT-Branch: master $:$NHDT-Revision: 1.128 $ */
 /* Copyright (c) Stichting Mathematisch Centrum, Amsterdam, 1985. */
 /* NetHack may be freely redistributed.  See license for details. */
 
@@ -567,6 +567,10 @@ struct obj *obj;
             !objects[otyp].oc_uses_known;
     bareobj.quan = 1L;		/* don't want plural */
     bareobj.corpsenm = NON_PM;	/* suppress statue and figurine details */
+    /* but suppressing fruit details leads to "bad fruit #0"
+       [perhaps we should force "slime mold" rather than use xname?] */
+    if (obj->otyp == SLIME_MOLD) bareobj.spe = obj->spe;
+
     bufp = distant_name(&bareobj, xname);	/* xname(&bareobj) */
     if (!strncmp(bufp, "uncursed ", 9)) bufp += 9;  /* Role_if(PM_PRIEST) */