Don't make callers responsible for losestr death

Remove callers' responsibility to deal with possible hero death when
calling losestr.  This is less fragile and error-prone than leaving it
in the caller's hands, but it means that death from the monster spell
'weaken target' no longer goes through done_in_by, and the death reason
is no longer "killed by <monster name>".

Don't use boolean for losehp killer format type

Killer format isn't a boolean, since it has 3 possible values
(KILLED_BY_AN, KILLED_BY, NO_KILLER_PREFIX).  It shouldn't make any
difference behind the scenes, but it's confusing to use 'boolean' for
it.

Fix: 'weaken target' spell against poly'd hero...

...could leave hero in creature form with negative u.mh

losestr can subtract HP, but doesn't directly kill its target.  The
caller is responsible for possibly killing the hero if losestr reduces
her HP to 0 or lower; most callers do this by combining losestr with a
losehp call, which can kill off the hero if necessary.

MGC_WEAKEN_YOU calls done_in_by if u.uhp < 1 after losestr, but didn't
handle the Upolyd u.mh case, so could leave a polymorphed hero with
negative health.  Add a rehumanize call in that case.

This could also be done by changing losestr to call losehp itself for
the HP loss it deals out, but this would interfere with
cast_wizard_spell's use of done_in_by to generate the death reason:
either all strength loss is described one way ("terminal frailty" or
something -- not great) or else losestr must be passed a death reason
and is described a different way than other attack spells (because it
wouldn't go through done_in_by).

fixes entry for PR #883 - digestion attack by hero

Pull request from entrez:  poly'd hero who digests a creature has a
change to gain an intrinsic from it.  I put the fixes entry in the
New Features section.

I was a bit concerned that g.afternmv might be cleared during the
turns the hero is busy digesting, leaving a stale value for
g.corpsenm_digested, but I don't think that that can happen.

Fixes #883

Digestion attack can grant hero intrinsics

Monster purple worms can now gain intrinsics from swallowing foes whole,
so maybe the hero should be able to do so too.  Intrinsics aren't
granted immediately upon swallowing (that would probably have been
easier), but only once a corpse is created and then entirely digested.

I'm not sure if this is too powerful and was being avoided deliberately
for that reason, since it includes potential level gain from wraith
corpses in addition to other intrinsics.  That's consistent with monster
purple worms but may be a bit too much in the hands of the hero, though
it is limited by needing the corpse creation roll to succeed.

couple of reformatting bits

Some formatting stuff left out of recent commits.  No change in
behavior.

mstrength prototype and preprocessor

just the one mstrength() for makedefs and game

gcc warning

be consistent in preprocessor conditional

during devel make it easy to review mon difficulty

Remove leftover debug pline

fix github issue #894 - guardian nagas can't grab

Issue reported by eakaye:  for a 'hugs' attack to succeed, the
monster must have at least three attacks and the two preceding the
hug attack need to both hit.  Guardian nagas had three attacks but
the first was melee 'bite' and the second was ranged 'spit'.  Those
are mutually exclusive, so they would never both hit and nagas never
grabbed their prey.

Make the spit attack be first, the bite attack be second, insert a
touch attack for 0 damage third, and make the hug be fourth.  Also,
change their hug damage type from 'phys' to 'wrap'.  The first and
2nd+3rd+4th are still mutually exclusive.

The resulting message feedback left something to be desired and has
been tweaked.

The difficulty-level formula used by deprecated 'makedefs -m' now
generates 17 rather than 16 for guardian naga so I changed revised
monster to match.  They are definitely more difficult now that their
constriction attack has a chance to hit.

Fixes #894

paste error

less specific re version to reduce doc maintenance

djgpp cross-compiler version update

do CI DOS build in single make command

warning fix

../win/curses/cursmain.c: In function 'curses_init_nhwindows':
../win/curses/cursmain.c:157:17: warning: unused variable 'pdc_font' [-Wunused-variable]
  157 |     static char pdc_font[BUFSZ] = "";
      |                 ^~~~~~~~
../win/curses/cursmain.c: At top level:
../win/curses/cursmain.c:157:17: warning: 'pdc_font' defined but not used [-Wunused-variable]

This is cron-daily v1-May-8-2022.  000files updated: Files

fetch-cross-compiler.sh directory check follow-up

fixes entry for pr889

Merge branch 'unicode' of https://github.com/chasonr/NetHack into pr889

A note on makefonts.lua

Make the Terminus fonts an external package

Credit to Michael Allison for the patch and for the previous one
to build the fonts in the cross-compile.

mhurtle_step() bit

A very splight simplification.

"no monster to remove" for steed knockback

Reported directly to devteam, mounted hero whose steed got hit
for knockback effect triggered impossible "no monster to remove".

In addition to fixing that, this makes a knockback attempt at a
hero who is stuck to a cursed saddle knock the hero and steed back
instead of knocking the hero out of the saddle.

mhurtle_step() should be able to use u.ux0,u.uy0 to update the
hero's old location after moving the hero in order to move the
steed, but the value was different from what was expected and the
map showed stale steed symbol when I used that.  I'm not sure what
is going on there; saving u.ux,u.uy before moving the hero worked
as intended so I didn't pursue it.

latest Xcode build issue

An Xcode update has started causing the same problem that was experienced on
Linux with newer compiler or glibc a while back.

˜
In file included from monst.c:6:
In file included from ../include/config.h:670:
In file included from ../include/integer.h:54:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:32:
/Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:302:39: error: too few arguments provided to function-like macro invocation
^
1 error generated.
make[1]: *** [monst.o] Error 1

 Please enter the commit message for your changes. Lines starting

more PR #891 - build fix

More tty-specific hangup handling.  There's still doubt about the
origiinal testing, but not about testing after "post bitrot repair",
if there was any.  That wasn't useful because the new code was
accidentally suppressed by testing a misspelled macro. when deciding
whether to include it.

github PR #891 - tty #if HANGUPHANDLING misspelled

Pull request from entrez:  the conditional hangup handling in
wintty.c hasn't been getting used because the HANGUPHANDLING macro
from the core was misspelled as HANGUP_HANDLING.

The old testing was probably invalid since it was most likely done
with the same misspelled #if.  I haven't done any new testing so
since this should be considered potentially buggy.

Fixes #891

Fix HANGUPHANDLING ifdef for TTY

The SIGHUP handling for the TTY windowport added in 594cb5f was wrapped
in '#ifdef HANGUP_HANDLING', but the actual define is 'HANGUPHANDLING'
without the underscore.

github issue #890 - hobbit #chat feedback

Issue reported by eakaye:  the alternate hobbit chat message is a
complaint about dungeon conditions, given if its current HP is 10
or more less than its maximum HP.  But since hobbits are level 1,
they will almost never have 10 HP so won't be alive to chat when
at max minus 10.

Keep the old behavior if maximum happens to be more than 10, but
give alternate feedback when less than max if max is 10 or less.

Fixes #890

Build fonts in the native build

Ignore the PSFs

Build the PSF fonts in the cross-compile

getting knocked off flying steed

I was trying to reproduce the reported "no monster to remove" warning
from remove_monster() when a mounted hero was knocked off jabberwocky
steed but so far haven't been able to.

While trying, I came across a more minor bug.  The hero got knocked
off a flying steed and got feedback of "you fly off" rather than
"you fall off".  Flying capability came from the steed and dismount
feedback is aware of that but calls u_locomotion() which isn't.  This
commit fixes that.

This adds some groundwork (DISMOUNT_KNOCKED) for better dismount
control.  With a map fragment of
|....
|.Du.
|....
I got knocked off my steed by the attacking dragon and ended up with
|..@.
|.Du.
|....
It would be better to prefer spot 1, then the 2s, then 3s, then 4s
(not sure about farther spots if none of those are available)
|.432
|.D@1
|.432
when forced to dismount by knockback.  This does _not_ implement that.

Merge branch 'unicode' of https://github.com/chasonr/nethack into unicode

Update the README for the fonts

Rewrite the makefont program in Lua

Support the DOSVGA build

More native compile fixes

* subst doesn't seem to work in variable assignments
* LUADLL isn't meaningful for MS-DOS

Updates to the native compile

Support wide Curses on MS-DOS

Also, fix IBMGraphics on Curses

Update the README for the fonts

fix wishing help for X11

Pass the wait-for-response arg when displaying the wishing help text
window.  tty, curses, and Qt waited regardless, but X11 honors the
no-wait request.  It was showing the text window then letting the
core immediately resume, resulting in reissuing the wish prompt on
top of the help window.  Entering a successful wish then dismissed
the prompt but left the help on the screen, possibly obscuring the
map depending on placement.

Rewrite the makefont program in Lua

Support the DOSVGA build

More native compile fixes

* subst doesn't seem to work in variable assignments
* LUADLL isn't meaningful for MS-DOS

Updates to the native compile

Support wide Curses on MS-DOS

Also, fix IBMGraphics on Curses

fix github issue #679 - orc strength

Reported by eakaye:  orcish hero has maximum strength of 18/50 but
hero poly'd into an orc was given 18/100 strength.  Also, a comment
from vultur-cadens pointed out that orcish heroes start with poison
resistance while monster orcs lack it.

Even though the boost to 18/100 is only temporary until the poly
times out, make orcs a special case where strongmonst from poly'ing
into them only gives 18/50 strength instead of 18/100.  Adopt the
suggestion that Uruk-hai be an exception and continue to give hero
poly'd into them 18/100.

If any gnome becomes strongmonst (currently none are), treat them
as 18/50 too.  Elvenking and elf-lord are strongmonst; treat their
forms as plain 18 though, matching the limit of elf heroes.  Lesser
monster elves aren't strongmost.

While in there, add another special case so that hero poly'd into a
giant gets 19 strength.  Monster giants are still plain strongmonst
so might warrant some sort of adjustment.

Give orcs poison resistance, but eating their corpses doesn't provide
an opportunity to confer it.  Note goblins and hobgoblins still don't
have the resistance (to distinguish them from orcs a bit).

Take away strongmonst from orc shamans and give it to orc mummies.
Human mummies should have it too (at least according to movies) but
I didn't alter them becuase they're already pretty dangerous at the
point they start occurring.  Take away strongmonst from plain 'elf'
placeholder.

New:  when hero polymorphs into a form that lacks the strongmonst
attribute, take away any exceptional strength (drop 18/01 through
18/100 down to 18; as mentioned above, the drop is only temporary).
There's no attempt to set the maximum even lower for wimpy forms.

Fixes #679

use Norep() for searching while engulfed

Suggested by entrez:  when you search while engulfed the feedback asks
whether you're looking for the exit, but the joke about the exit isn't
funny when repeated over and over which happens if the player waits to
be expelled by using 's','s',... rather than '.','.',....

fix #K3739: engraving in dust mentions frost

[sic] should be "engraving in frost mentions dust"

Writing on ice with fingers is described as writing in frost, but if
you overwrite an existing engraving rather than add to it the game
said you wiped out the engraving in the dust (immediately followed
by writing in the frost).

Not mentioned in the report:  finishing a multi-turn engraving on
ice had the same problem.

fixes entry for PR #884 - X11 extended command

Pull request from entrez:  X11's get-extended-command widget
allocated 1 extra byte for a couple of end-or-array terminators
and then wrote more than 1 byte to them when initializing its list
of extended commands.

Fixes #884

Fix: X11 extcmd menu heap buffer overflow

Instead of allocating space for ((n + 1) * size) (to make room for all
entries plus terminator), it allocated space for (n * size + 1).
init_extended_commands_popup would therefore write past the end of the
memory allocated for command_list and command_indx when trying to store
their respective terminator entries.  This meant the X11 windowport
would crash when accessing the extended command menu, if NetHack had
been compiled with -fsanitize=address.

I also did some minor cleanup/refactoring to eliminate variables and
lines that were made redundant or useless by 9d64d13, which changed the
way the function worked and removed the need for things like tracking
indices in the source and destination arrays with separate variables.

a couple of warnings

curses: scrollbars on clipped map

A change to the curses interface from three years ago to make sure
that round-off didn't make the horizontal and vertical clipped map
indicators appear to not be clipped was using ROWNO for both instead
of COLNO for the horizontal one.  For modest clipping the mistake
was unnoticeable; I don't know whether that remained true for more
extreme clipping.

[Not fixed:  the curses scrollbar stuff ignores the fact that map
column 0 is unused.]

huge chunk of meant name change not comprehensive

warning: for tile 250 (numbered 250) of objects.txt,
        found 'huge chunk of meat' while expecting 'enormous meatball'
../win/share/objects.txt: 460 tiles

more genocide prompts

Make the prompt for single genocide be more precise
 from:  What monster do you want to genocide?
 _to_:  What type of monster do you want to genocide?
and the re-prompt for it be slightly more verbose
 from:  What... [type the name of a monster]
 _to_:  What... [enter the name of a type of monster]

Also, make the already verbose re-prompt for class genocide even
more verbose
 from: What class... [type the symbol representing a class]
 _to_: What class... [type the symbol or name representing a class]

Possibly should have changed 'type' to 'enter' on the last one to
keep them consistent but I left that as-is.

pull request #882 - prompting for genocide target

Pull request from entrez:  genocide prompt has a short explanation
appended.  Skip that on first try, and on all tries if 'cmd_assist'
option is Off.

For class genocide, don't retry an unlimited number of times if
player supplies an empty response.  Any empty response will now
count toward the 5 chances available to supply a valid choice, as
it does with single genocide.

Fixes #882

Show genocide prompt help iff 'cmdassist' enabled

The "[type the name]" prompt seems appropriate for handling via
cmdassist, so experienced players who don't need the help can hide it.
I also added a corresponding help note for the class genocide prompt.

Don't screen out empty input in class genocide

So that a blank line wouldn't use up one of the player's "tries" for
class genocide, the game would continue to prompt until the input was
non-blank (or the user hit <esc>), with a tight loop around the getlin
call that only exited when it got some non-empty input.  This apparently
risked leaving the game endlessly looping under some worst-case-scenario
hangup conditions.  It was also inconsistent with normal genocide, which
doesn't have special handling of blank lines.  Make the class genocide
prompt behave like the normal genocide prompt by removing the "blank
input" loop (and consequently treating a blank line the same way as any
other attempt to write a name).

fixes entry for pull request #881 - curses exit

Pull request from chasonr:  if the curses interface did a full screen
update while the game was ending, it could attempt to refresh windows
that had already been removed.

For #if PDCURSES, raw_print() could attempt to write to the message
window after it had been removed.

[Why is raw_print() using the message window at all?  Isn't the main
point of it to bypass that?]

Fixes #881

Fix undefined behavior when exiting Curses

* When saving: curses_exit_nhwindows calls curses_uncurse_terminal,
  which calls endwin. curses_exit_nhwindows then calls raw_print,
  which calls more Curses functions after endwin has been called.
  Fix this by having curses_raw_print use puts if window_inited
  is false.

* When dying, quitting, etc.: really_done opens the "Goodbye" window,
  which refreshes the other windows when it closes. But the status
  window (and possibly the map and message windows) are gone by that
  point. The window pointers are properly NULLed, but the NULL is then
  passed to touchwin. Fix this by checking window pointers for NULL.

github pull request #859 - IS_SUBROOM_INDEX

Pull request from entrez:  fix an off by one error in the allowed
range of subroom indices.

I've never understood subrooms and am accepting this fix on faith.

Fixes #859

Fix: IS_SUBROOM_INDEX range

The macro (currently unused, I think) for checking whether a particular
index designates a subroom was off by one on the maximum allowable
value.

Because of the dedicated extra space for the g.rooms array terminator
flag (hx == -1), subroom indices in g.rooms are set out in the range
[MAXNROFROOMS+1, MAXNROFROOMS*2], inclusive.

Also some minor formatting tweaks.

github pull request #733 - prices of unID'd gems

Pull request from vultur-cadens:  don't change unID'd gem prices
when source changes insert some new object before them or the game
gets rebuilt with different featues enabled such as MAIL.

This is more about keeping the spoiler table in the wiki accurate
than anything to do with game play.  It definitely gives players
who use spoilers an advantage over ones who don't, but does so in
such an insignificant aspect of play that it likely doesn't matter.

I'm fairly sure that the remark that keeping the prices the same
is what the original implementor intended is not correct.  I don't
recall who implemented this and the commit log for the first cvs
repository is long gone so it's moot.

Fixes #733

Unidentified gem selling prices

Make the token selling prices for unidentified gems not depend on how
many items were defined before FIRST_GEM.  Now the unidentified gem
selling prices will depend only on the number and defined order of the
types of gems, and won't inexplicably change when objects are added,
or depend on compile-time options such as MAIL.

Also don't do the regular item price reduction for unidentified gems,
since they are already not based on the actual value.  This restores
the pre-3.6 behavior, allowing players to gain a bit more information
from the nominal selling prices of unidentified gems.

Whoever first introduced this special handling for gems probably
intended for players to be able to gain information from gem prices
this way, but probably nobody has been doing it since 3.6.

rename "huge chunk of meat" to "enormous meatball"

Pull request #607 by Vivit-R proposed renaming "huge chunk of meat"
to "giant meatball" to better reflect the similarity to meatball.
But an object name that contains a monster name prefix requires extra
work in the wishing code.  I considered "huge meatball" which retains
more of the original name but decided to go with "enormous meatball"
becaues it seems more evocative.

Supersedes #607
Closes #607

__attribute__(returns_nonnull)

Refine commit 4885653014e6651118e58315e95c7655539ca21b.

> I'm not sure whether gcc 3 is really the right test for whether the
> returns_nonnull attribute setting is available.

The gcc.gnu.org website only goes back to 5.1, and searching the
documentation of that version for returns_nonnull finds it.  I used
ftp to get gcc-core-3.0.0 and gcc-core-4.0.0 and their doc files don't
mention this attribute.  It might have been added for some later 4.x
but that really doesn't matter for nethack's purposes.

Use __GNUC__ >= 5 instead of __GNUC__ >= 3 when testing whether
__attribute__(returns_nonnull) is available.

windowborders menu bit

The menu to interactively set the windowborders option for curses
uses 'a'..'e' for choosing 0..4.  Accept '0'..'4' (via unseen group
accellerator) too.

more TTYINV=4 - lamps/leashes

When persistent inventory is set to only show items-in-use, include
leashes attached to pets and lit lamps and candles, same as the '*'
command.

TTYINV vs end-of-game disclosure

If environment had TTYINV=4 (perm_invent shows worn/wielded only),
disclosing inventory at end of game only showed worn and wielded
items instead of full inventory.  Didn't matter whether perm_invent
is On or which interface is in use or whether game was built with
TTY_PERM_INVENT enabled.

object name assignment vs persistent inventory

This is an alternate way to deal with pull request #876, where
splitting a stack that has a name assigned updated perm_invent when
cloning the name and ran into trouble with shop billing when trying
to format for persistent inventory display.

The PR#876 fix has been left in place but wouldn't have been needed
if this had gone in first.

fix #H5459 - explosions and steeds

Reported nearly five and half years ago:  mounted hero and steed
shared resistances if they got hit by an explosion.

fix "unique monster doppelganger and bones bug"

Reported by paxed 8 years ago:  if a bones file contains a
doppelganger imitating a unique monster, when it gets loaded
that monster ends up being marked as having been created.  The
doppelganger itself will shapechange to other forms, but the
unique monster won't be created when it should be because it has
become extinct.

Report involved creating a statue of a unique monster which
yields a doppelganger in that monster's shape, then using stone
to flesh to animate the statue, dying before it changes to some
other shape, and having bones be saved.

pull request #850 - level teleporter feedback

Pull request from copperwater:  don't give "flash of light" feedback
when activating a level teleporter because it's too much like one of
the outcomes of a magic trap.

This doesn't use the suggested commit.  Getting the "you feel
disoriented" feedback before being asked for destination level (when
having teleport control) seemed contradictory.  This gives different
feedback and does so after the actual teleport.

Supersedes #850
and since nhcopier doesn't seem to understand "supersede"
Closes #850

alloc() never returns Null

Mark alloc()--also dupstr() and re_alloc()--for gcc and clang as
always returning non-Null.  This should silence some of the static
analysis complaints.

Almost all the monster and object naming functions (anything that
returns an mbuf or an obuf) should be marked this way too but I'll
leave that for somebody else to deal with.

I didn't attempt to mark alloc() with the 'malloc' attribute because
macro definitions could end up causing trouble.  Specifying its
deallocator would probably be useful but is at even bigger risk of
macro interference.

I'm not sure whether gcc 3 is really the right test for whether the
returns_nonnull attribute setting is available.

Fix curses cursor keys

My change to allow fuzzer run in curses caused the cursor keys
to not work (eg. paging through menus with left and right cursor),
so fix that.

italic attribute on tty

If switching to italic isn't supported for tty, switch to underline
instead.  Comparable to the curses interface.

fix github issue #581 - "You see no door there."

Year old issue from copperwater:  'open' directed at a non-door told
player that there isn't a door and took no time unless character was
blind and learned what type of terrain it is, applying a key gave
the same message but used a turn and didn't update map to reflect any
terrain discovery.

Attempting to open an adjacent door or applying a key to one while in
a pit had a similar issue:  they produced the same "you can't reach
it from here" but had different time vs no-time outcome.

There may be other actions in the same situation.

Closes #581

github PR #868 - fix replacement of 'w' terrain

Pull request from copperwater:  terrain replacement couldn't match
'w' because it only checked actual terrain types.

Fixes #868

Make replace_terrain respect fromterrain='w'

Noticed that an attempted terrain replacement wasn't taking hold even
though 'w' is supposed to mean "match any stone or wall"; this was
because w converts into non-terrain-type MATCH_WALL and replace_terrain
was doing a simple comparison on whether the potentially replaced
terrain matches that type. Add a special check here for w so it will
match the terrain types it's supposed to.

Note that using replace_terrain with 'w' now WILL match stone, since
this is the documented behavior of w, to match IS_STWALL rather than
just IS_WALL. If a level designer really wants to exclude stone, they
can work around this by either making a selection and filter out stone
terrain, or doing two replace_terrains with '-' and '|'.

fixes entry for PR #848 - no traps in Tou shops

Pull request from copperwater:  the random traps specified by the
special level definitions of the tourist locate and goal levels could
be placed inside the shops present on those levels.

Fixes #848

Fix: prevent traps in shops in the Tourist quest

The Tourist locate and goal levels have 2 shops each, and also have
various traps randomly placed on the level. Unfortunately, this does not
account for placing them in the shops, so it was possible to wind up
with a magic trap or falling rock trap or whatever inside the shop,
which the shopkeeper would not clean up.

This commit makes selections that exclude the shop areas, and picks the
traps from those selections, keeping the shop floors trap-free as their
customers expect.

dgn_bottom() fix

Use the level passed in instead of the hero's location when checking
the dungeon branch.

It probably doesn't make any difference, but use the argument that's
already being provided.

vibrating square

Give a [probably pointless] hint if the player tries to move '>'
while on the vibrating square.

refine bottom of Gehennom check

In the quest branch, dbg_bottom() returns a barrier level rather
than actual bottom.  Do things the same way for the gehennom branch.

'fix' #K3716 - engraving with Fire Brand

Add a comment to the effect that engraving with Fire Brand doesn't
cause it to become dull.

[I'm not sure that is the behavior we really want.  It seems like an
unintended side-effect of changing Fire Brand's engrave type to BURN.]

'fix' #K3676 - artifact_hit()'s magr

Someone asked whether the 'magr' argument to artifact_hit() can be
Null or not since the code sometimes checks whether it is Null and
other times uses it unconditonally.  The answer is "it depends."
Can't reply to asker due to forced anonymity when the contact form
was submitted.

Curses: enable debug fuzzer

Prevent impossible fall dmg if falling up

The way hole destinations work now theoretically allows for a
cross-branch hole or trap door to move you across branches in a way that
decreases your overall depth.  If this happened, it would cause an
impossible when the negative result of (depth(new) - depth(old)) was
used to calculate fall damage.  Limit fall damage to 1d6 if dist <= 0.

Apply trap door destination restrictions in dodown

Missed this way to use the trap door (in a block added in 05761ba) in
previous commits, though I'm a little confused about whether that block
in dodown is even reachable given how various trap scenarios are handled
with dotrap earlier in the function.

Apply dest. limit to monster trap door usage

To prevent monsters from falling past the bottom level or into the
sanctum early, and to maintain consistency between monster and hero hole
usage.

Refine attempt to clamp trap door fall destination

This should prevent anyone from exploiting falling into the sanctum (by
taking advantage of a trap door in a bones file from a differently
laid-out dungeon, as described in the previous commit) to bypass the
invocation, in addition to falling past the actual end of the dungeon.

Prevent hero from falling past end of dungeon

Similar story with saved trap door destinations: if a bones file near
the end of the dungeon came from a longer dungeon (i.e. with a
lower-depth castle) than the one the bones file is loaded into, the
trap door destination could be past the dungeon end.  Clamp the
destination so it won't be lower than the bottom level of the dungeon.

Have monsters' hole destination match the hero's

The fixed destination of a hole or trap door was being used for the hero
but not for monsters.  Make everyone land in the same place, so you can
chase a monster into a hole and actually find it.

Fix: antigravity trap doors

Trap doors saved their destinations as an absolute level, rather than a
relative one, so if you loaded bones from a special level their
destinations would reflect the dungeon layout from the bones player's
game.  For example, die on the Oracle level, on dlvl5, with a trap door
that goes to dlvl6.  Another player gets those bones on their Oracle
level, which is dlvl8... the trap door would still go to dlvl6.  Pretty
amazing trap door -- something you might see in a funhouse!

Include relative rather than absolute destinations in save and bones
files, much like stairs do, to avoid this problem.

I bumped EDITLEVEL because although this won't break save files in an
obvious way, it will interpret the (absolute) destinations in existing
save and bones files as relative, leading to some crazy long falls. :)

github pull request #628 - duplicate code

Pull request from argrath nearly a year ago: an 'if' and corresponding
'else' have the same code so there's no point in testing for if/else.

I'm still not convinced that simply removing the if/else is the right
fix here but nothing else is going on.  I've put part of the removed
code back inside '#if 0' in case it needs to be resurrected someday.

Closes #628

remove duplicate code

Here, `then` clause and `else` clause is identical.

github PR #879 - pets eating shapeshifter corpses

Pull request from entrez:  the check for whether a pet in desperate
straits will eat a corpse that will cause it to polymorph used bad
logic.  The suspect code was added post-3.6.

Fixes #879