light source troubleshooting

I don't think this solves the recent light source reports,
but it changes a couple of things in an attempt to get more
information.

1. Having gy.youmonst.m_id field always be zero makes it tough
to distinguish it from uninitialized memory, or a random memory
value. This changes the m_id for the hero's gy.youmonst.m_id
to always hold the identifier 1, instead of 0.

2. write_ls was taking the stashed pointer in the light source,
and using it to immediately extract the m_id field and search
for that m_id. This changes the approach slightly, to actually
try and locate the stashed pointer itself in one of the monster
chains. Only if the monster pointer is located, do we dereference
it to obtain the m_id field.

3. For the interim, mark the saved ls with another set bit when
there has been a failure to locate the monst. At this time,
no code is acting on that bit, but it can be seen in a debug
session.

Hopefully, the next report will provide enough information to
understand the scenario a little better.

include/hack.h

@@ -1256,11 +1256,12 @@ typedef uint32_t mmflags_nht;     /* makemon MM_ flags */
 /* flag for suppressing perm_invent update when name gets assigned */
 #define ONAME_SKIP_INVUPD 0x0200U /* don't call update_inventory() */
 
-/* Flags to control find_mid() */
+/* Flags to control find_mid() and whereis_mon() */
 #define FM_FMON 0x01    /* search the fmon chain */
 #define FM_MIGRATE 0x02 /* search the migrating monster chain */
 #define FM_MYDOGS 0x04  /* search gm.mydogs */
-#define FM_EVERYWHERE (FM_FMON | FM_MIGRATE | FM_MYDOGS)
+#define FM_YOU 0x08     /* check for gy.youmonst */
+#define FM_EVERYWHERE (FM_YOU | FM_FMON | FM_MIGRATE | FM_MYDOGS)
 
 /* Flags to control pick_[race,role,gend,align] routines in role.c */
 #define PICK_RANDOM 0