More cleanup and flag setting refactor - part 1.

[wyld-sw]

This addresses p_db.c issues by refactoring sanity checks, moving variables to required scope, and moves to brace-required style for control flow. Please let me know if any of this has unexpectedly modified the logic.

More errors about errors

Recent use of snprintf for error messages (and a few stack items) should no longer produce a warning.

Consistency Crusade (let me know if these don't make sense to do)

• ENTRANCES_ARRAY now requires mlev 3, since NEXTENTRANCE does.
• RMATCH now strips ansi, since MATCH does.

Need Input

• Asking for the link of program objects gives an error. A previous maintainer suggested that programs would be implicitly linked to their owner. I could extend that to say that this "home" would be set at creation, and only modifiable through the @chown process. Is this a good idea?
• CONTENTS can return a different object for mlev 1 (no dark or non-controlled object). It doesn't seem that CONTENTS_ARRAY has this restriction. Should it only return a limited array for mlev 1?

The stage is SET

This PR features the start of a flag-setting refactor. This may have ended up as mostly moving code around, but there were a LOT of iterations and testing involved. Please check to see I haven't inadvertently prevented or allowed something that I shouldn't have.

Both SET and @set now call the "unable_to_set_flag" function, which takes the old restricted() function and adds some checks that hadn't been addressed in both processes. Specifically:

• @set should now ensure that the OVERT and YIELD flags are only (re)set on players and things.
• SET should now respect the force restrictions for interacting with MUCKER/NUCKER bits and should not allow wizards to make themselves mortal.

Interaction between players/programs and MUCKER/NUCKER bits were carefully considered with this refactor, but I may have missed something. Please review and test this logic.

Still TODO

• Unifying name-set, owner-set, recycling, link-resolution, and link-set logic between primitives and server commands sounds like a good idea.
• Documenting the use of the object timestamp functions should lead to a better understanding of when and why these are, or should be, used. I'll add an Issue for this soon.

[tanabi]

Regarding programs and linkage ...

I don't think I ever noticed that program objects can't be linked somewhere, because I did know they could be swept so I kind of assumed they could have a home. This lead me to dig into the code, and I can see sweep's MUF does a MOVETO #-3 which, in turn, in moveto in move.c makes it go back to the owner in a very hard coded kind of way.

It makes me wonder why programs can't be linked somewhere. I have known many MUCKs where they dump the MUF objects into some kind of landfill room (usually called a library, but essentially a landfill) just so wizards aren't carrying them around constantly. Having the programs return to their owner isn't necessarily a desired effect.

So the question, I believe, really becomes -- should we allow programs to be linked to something? Is the 'home' field of a program object used for something I don't remember? This should probably be its own issue -- I would favor just leaving things as they are for programs until we dig into this more and maybe just take the 'special case' status off program scroll objects.

...

CONTENTS and CONTENTS_ARRAY should most definitely have all the same restrictions. I'd say go with CONTENTS' restrictive level.

...

[wyld-sw]

Hoo boy. This is a monster! A lot of refactoring.

Now, I know when I ask this, you're going to suggest I test it, too, and I should. But! I have to ask, have you tested each of these nooks and crannies you've just shifted around? :D

If your confidence level is high, great; if it's not, we might aught to make a little checklist and go through it to make sure nothing breaks in this.

Hoo boy. This is a monster! A lot of refactoring.

Now, I know when I ask this, you're going to suggest I test it, too, and I should. But! I have to ask, have you tested each of these nooks and crannies you've just shifted around? :D

If your confidence level is high, great; if it's not, we might aught to make a little checklist and go through it to make sure nothing breaks in this.

I've definitely tested it, and it all seems to work. Though as you said it's a lot, and something may have snuck in, or I didn't quite get the MUCKER/NUCKER split quite right. A checklist might not be a bad idea, but I'm definitely OK following whatever your suggestion is.

I'd be happy to re-test any part of that list - and feel free to tell me to pull this back and do it in stages.