Enable additional built-in commands for single player only

[GooberRF]

This PR adds support for the additional built-in RF console commands listed below in release builds, while restricting their use to single player only for obvious reasons.

Command list:

• drop_clutter
• drop_entity
• drop_item
• teleport
• pcollide

For the first 4 listed commands, it's sufficient to simply disable access to the command in multiplayer (since they are relevant only for the level/instance in which they are entered). For pcollide, I've also added a step when initializing multiplayer to force it on if it's currently off, following the same method already used for the debug rendering subcommands.

Two additional very minor changes also included in this PR are:

• Add entity_lookup_type method to entity.h: Added this because I initially supported body in single player as well, but decided against because it's of very little use to players but its behaviour can be confusing. Thought there was no harm in keeping method in entity.h anyway though for later utility.
• Remove difficulty command from debug build register commands list: Unnecessary because it's already registered in all builds.

[is-this-c]

Probably cleaner to inject wherever collides_with_world is checked instead. But I do not like that you are exposing teleport and especially pcollide to the typical user. Why?

[GooberRF]

Probably cleaner to inject wherever collides_with_world is checked instead.

Why? It's definitely possible I'm missing something, but to my understanding it's far, far cleaner to set the collides_with_world value itself and let the game check it (as it always has) rather than injecting into the place where it's checked and forcing a value.

I also kept this function flexible, in case in the future there are other values that should be checked, set, verified, clamped, etc. before MP is loaded.

I do not like that you are exposing teleport and especially pcollide to the typical user. Why?

Each definitely has use cases for single player map/mod developers in testing for their projects. The usefulness of teleport is likely far less than pcollide, but both definitely have a use. I can attest first hand that I would use both during my development workflow.

Moreover... why not?

While I would be opposed to adding launcher tickboxes or UI buttons for commands like this, providing safe, single player-only access to commands like this via console has literally no downside, and is relatively standard/expected for similar games. Very few FPS games, especially from RF's time period (at least those that have a developer console), do not allow access to a noclip command for example.

[is-this-c]

Why? It's definitely possible I'm missing something, but to my understanding it's far, far cleaner to set the collides_with_world value itself and let the game check it (as it always has) rather than injecting into the place where it's checked and forcing a value.

I also kept this function flexible, in case in the future there are other values that should be checked, set, verified, clamped, etc. before MP is loaded.

Imo it is just hacky to have to override values before MP is loaded.

While I would be opposed to adding launcher tickboxes or UI buttons for commands like this, providing safe, single player-only access to commands like this via console has literally no downside, and is relatively standard/expected for similar games. Very few FPS games, especially from RF's time period (at least those that have a developer console), do not allow access to a noclip command for example.

If teleport and pcollide are surfaced and every player in multi learns about them I believe it may easily materialize an interest to use them in multiplayer. I think it is made worse because Dash Faction's anticheat is not first class e.g. scoreboard does not show other players' anticheat status.

[GooberRF]

Imo it is just hacky to have to override values before MP is loaded.

IMO it's far more hacky to inject into the place the value is checked as opposed to setting the value that is to be checked via the game's standard mechanism.

If teleport and pcollide are surfaced and every player in multi learns about them I believe it may easily materialize an interest to use them in multiplayer. I think it is made worse because Dash Faction's anticheat is not first class e.g. scoreboard does not show other players' anticheat status.

Unless I'm misunderstanding, the suggestion here seems to be that features that would be useful to mod developers (and tbh just SP players) should be kept obscured from them on the basis that other people simply being aware of the existence of those commands might be incentivized to create debug builds (which they already can do) and then use them in multiplayer to cheat in extremely obvious ways?

Not only does that seem exceedingly unlikely to me, and a huge stretch, but I would argue that if that were a concern, the current state is actually worse - currently anyone who does want to use these functions in SP only must use a debug build to do so, which has no protections against them then using them in multiplayer.

I don't view this as a fair or relevant concern in any event, but even if it were, the existence of these functions is already quite clear to anyone with the desire and means to exploit them in multiplayer.

Current state: Few people know the functions exist, so few are able to derive legitimate/honest value from them. Everyone with access to the functionality is extremely well equipped to use them to cheat in MP if they so choose.
State after this PR: More people know the functions exist, and can derive legitimate/honest value from them. The majority of people are prevented from using them to cheat in MP, though if they separately make a debug build, then they could do so (no change from current state).

The premise that useful functionality should be kept from those who would derive value from it because other people might want to use it to cheat (through a method already available to them today) is fundamentally flawed, in my view.