Expose client version information in non-debug builds

[rollerozxa]

Closes #14151.

The client version information that has previously only been available in debug builds are now always available. Serialisation version and client status still remain behind the debug check.

To do

This PR is a Ready for Review.

How to test

e.g. worldedit //lua command in singleplayer:

//lua minetest.log(dump(core.get_player_information("singleplayer")))

[rollerozxa]

The PR has been changed to only expose the version string field now.

[appgurueu]

I'm fine with the PR in the current version (pun intended)

[sfan5]

I think what we should do to further discourage doing version comparisons is to actually provide documentation on which protocol version maps to which engine version (or perhaps just link to networkprotocol.h?).
As it is now the docs tell you to use the protocol version but there isn't a single word on how.

[sfan5]

IRC:

17:21 		<luatic> "I think what we should do to further discourage doing version comparisons is to actually provide documentation on which protocol version maps to which engine version"
17:24 		<luatic> I recall the original suggestion also being the addition of APIs. Could a simple table that maps engine version names to protocol versions suffice? So modders could do something like client_proto_ver >= core.protocol_version["5.9"].
17:55 	sfan5 	@luatic: sure

[appgurueu]

I took the liberty to implement this. Is it fine now?

One minor question perhaps: We want core.protocol_versions to not contain patch versions, even if they entailed a protocol version bump, correct?

[y5nw]

Makes sense.

[grorp]

One minor question perhaps: We want core.protocol_versions to not contain patch versions, even if they entailed a protocol version bump, correct?

Hmm, I feel like it's inconsistent to leave a protocol version out just because it corresponds to a patch version. The reason to bump the protocol version for a patch version would be to make it detectable on the server, so leaving it out of the mechanism for making detection easier doesn't make sense. In builtin, one of the two cases where the protocol version is used for client feature detection is actually the 45/5.9.1 case.

[grorp]

could you make it explicit on core.features and core.has_feature above that they're for server-side feature detection? so we get a clear differentiation between server-side feature detection and client--side feature detection