Add many limits to settingtypes

[Wuzzy2]

This PR adds the missing upper and lower limits to many settings (int and float) in settingtypes.txt. Now I will describe how I came up with those limits:

• Limits found by testing: I used a manual binary search for control/rendering-related settings to find the point at which problems start to occur, then I reduced the value a little above that point (as a "buffer") and used that as a limit. There are the settings for which I did it:
  • mouse_sensitivity: Above 10 it's very fast and hard to control, it is close to being unplayable. At 100 (current limit in source code) it's completely unplayable.
  • cloud_radius: Serious render bugs start to occur above ca. 65. Clouds disappear completely, error message in console: "Too many vertices for 16bit index type, render artifacts may occur.". Note this is not the same as the "sharp cutoff" as stated in the description
  • 3d_paralax_strength: Beyond -0.087 or 0.087, the camera goes wild at certain or all view angles, making it unplayable
  • hud_scale: HUD is de facto unusable below 0.1
  • gui_scale: Below 0.5 it becomes too hard to use (tested at multiple resolutions, big and small)
  • font_size (and similar): 5pt is the smallest size in the default font at which I still can make out letters, barely. At 4pt, it's just a pixel mush. At 1000pt or above, Minetest crashes. At 72pt, the interface starts to break down (Minetest clearly isn't made for large fonts)
  • view_bobbing_amount: Above 56 the effect is so strong, the camera moves below the ground. Above 16, the camera often moves into the left or right wall when you walk on the center of the node
  • movement_liquid_fluidity: Can't be safely 0 like the other movement_ settings because of a division by 0 and you'd get teleported to (-nan, -nan, -nan) if you touch any liquid.
• Limits set for other reasons:
  • chunk_size: The description says there is no reason or benefit for this to be above 5, so 5 is the upper limit then.
• Mapgen Y limits: For all mapgen settings that ask for a Y height, it's always (-31000, 31000). In the code, those are s16 anyway.
• Mapgen taper height: 32767 because those always use s16
• Technical limits: 255, 32767, 65535, 2147483647, 4294967295 and 18446744073709551615 were used as upper limit when there was no other reasonable upper bound, in order to match the C++ data type limits (u8, s16, u16, s32, u32, u64).
• Logical limits: I often used 0 or 1 as lower bound for logical reasons, e.g. minimum waiting time, distances can't be lower than 0
• Special lower bound: Sometimes, the number 0 or -1 has a special meaning, so I used that sometimes as a lower bound
• No upper limit: Rarely, usually when it's based on Lua code (builtin), I placed no upper limit. Many floats also have no upper limit. For some settings, I had no idea what to do, so I also placed no upper bound

The overal idea here is, when a (previously permitted) value causes crashes, render bugs, or similar, it must be moved out of the allowed range. And then apply somewhat of a buffer as a "safe zone", just in case.

As for performance, I generally used the maximum value of the C++ data type because those values might work in theory if you have strong enough hardware.

I also made minor changes to the setting descriptions, usually for mentioning the missing unit (milliseconds or seconds).

To do

This PR is ready for review.

How to test

First, just read the changeset and my justifications above and think whether the new number makes sense.
Especially complain if you think a range is too small and there are reasonable values beyond the range I chose.
Also complain if you think that any in-range value might lead to errors, crashes, etc.

Then, check if the All Settings menu still behaves properly.

[Wuzzy2]

Fixes #8979.

[SmallJoker]

This won't fix the underlying problem though. These limits should primary applied on engine-side.

[Wuzzy2]

I know. That's not the goal here anyway. Consider it as some kind of documentation and/or first step. As for the engine side, I think it makes sense mostly for those values for which I have determined breakage.

[appgurueu]

This won't fix the underlying problem though. These limits should primary applied on engine-side.

Are the limits in settingtypes.txt not enforced?

[SmallJoker]

Are the limits in settingtypes.txt not enforced?

Some are rangelimed for extreme cases, some aren't. There's yet no settingtypes.txt parsing by the C++ engine.

[lhofhansl]

I have used 3d_paralax_strength of 0.1 with good effect. (with anaglyph)

[Wuzzy2]

@lhofhansl: Look exactly downwards or upwards. Camera starts shaking.

[Extex101]

I tested out some of these beyond limits, managed to get some pretty crazy effects with view_bobbing

When you walk and stop when the tilt is super insanely high and fly you can get a camera tilt effect

[SmallJoker]

(rebase needed)

[Wuzzy2]

Rebase done!

[Wuzzy2]

Rebase done!

[Zughy]

( @Wuzzy2 you're a triager as well, please remove the label by yourself next time. Same for "Adoption needed" in the other PR you've just closed)

[SmallJoker]

Better than nothing. I'll work on the C++ side to ensure the limits are actually enforced.

[Wuzzy2]

@rubenwardy: Done.