Choose terrain levels from what the screen can resolve

Levels changed at fixed distances - 512 m, 1 km, 2 km and on - whatever the window, the
field of view or the zoom. Now a level is used out to the distance where one of its sample
spacings covers terraindetail pixels on screen, 3 by default, which follows from the
viewport height and the vertical field of view with the zoom applied; each level doubles
the spacing, so each doubles the distance. Zooming in or a taller window pushes detail
further, a coarser setting pulls it in. The finest range never drops below four tile
sides, which the morphing needs to close the seams.

Levels and morphing both follow the finest range the last scan used, so they always agree,
and a change of more than a percent - a zoom, a resize - triggers a rescan.
tools/terraincook/seamcheck.py now also tries finest ranges of 5.7 and 11.3 tiles, and
finds no gap in any of them.

terraindetail is in the ini and on a slider in the debug panel; the panel's level table
and the residency line in the log show the resulting ranges. On baltyk the current window
works out to 484 m, so the 512 m minimum applies and nothing changes by default; a
scenery setting terraindetail 1 got 1349 m, and the samples on the gpu went from 3 MB to
10 MB with it.

utilities/Globals.cppm

@@ -196,6 +196,9 @@ struct global_settings {
     // how far terrain tiles are streamed and drawn, independent of BaseDrawRange: a baked
     // heightfield is cheap far out, and seeing it to the horizon is the point of having it
     float TerrainRange{ 20000.f };
+    // pixels one terrain sample spacing may cover on screen before a finer level takes over.
+    // smaller is sharper and costs more tiles at their finest
+    float TerrainDetail{ 3.f };
     int DynamicLightCount{ 7 };
     bool ScaleSpecularValues{ true };
     std::string GfxRenderer{ "default" };