Track what cooked data was made from, and cook it as a step of its own

A baked heightfield was trusted for as long as its file was readable, and the logic
container while the .scn was older than it: an edited include went unnoticed by both,
and node keys leaned on file dates, so merely touching a file changed them. And cooking
only ever happened as a side effect of starting a scenery.

Every cooked artifact now has a manifest beside it - <scenario>.ehf.deps,
<scenario>.logic.deps - listing each file it was made from with its size, modification
time and a hash of its content (simulation/cookdeps). The parser records what it
includes as it reads, so the list is exactly what the load read. An artifact is current
when every listed file still has its content: size and time are the quick check, and
when either differs the content is hashed, so a touched or copied file does not force a
rebuild and an edited one always does. A file added to the scenery cannot be in a
manifest; the files read are compared with it after the load, and a mismatch sends the
terrain to be baked on the next start - the new file's nodes, whose keys are unknown,
are drawn as geometry meanwhile - and the logic, cooked from the loaded state, is cooked
at once.

The terrain depends on what the scenario includes and not on the scenario file itself,
which the launcher rewrites on every start; the logic depends on both, since events can
be written in either, and costs milliseconds to cook again. With the manifest vouching
for file content, a triangle node's key is its file, line, include parameters and
placement, without the date.

-cook loads a scenery, brings whatever is stale up to date, and quits: the step that
prepares a scenery ahead of play. It closes the window directly, as there is no
simulation to wind down; a quit command waited a minute in the queue for one. Baking on
a first start stays as the fallback, and -nobaketerrain still turns it off.

Tried on a copy of baltyk with a terrain include of its own: a fresh cook bakes and
cooks everything, a second finds nothing to do, a touched file changes nothing, an
edited include is caught by its hash and both artifacts are rebuilt, and a new include
has the logic recooked at once and the terrain on the next run. A cooking run of baltyk
takes 5.5 s with nothing stale and 10.7 s with everything to do.

simulation/terrainbake.cppm

@@ -35,11 +35,11 @@ export {
 // triangles the heightfield really shows stop being drawn on their own, so nothing can vanish
 // from the scenery - the worst a bad bake can do is draw something twice.
 //
-// A triangle node is recognised by the file and line it is written at - with that file's size
-// and modification time - the parameters its include was given, and the origin and rotation in
-// force, not by its position in the load. An edited file changes the keys of everything in it,
-// and those nodes are then simply drawn again instead of the wrong ones being dropped. Hashing
-// the node's text instead would cost a second parse of every triangle node in the scenery.
+// A bake is used only while every file the scenery included when it was made still has the
+// content it had (cookdeps): the scenario file itself is not among them, since the launcher
+// rewrites it on every start and the terrain lives in what it includes. Within a bake that
+// holds, a triangle node is recognised by the file and line it is written at, the parameters
+// its include was given, and the origin and rotation in force.
 //
 // The rasterising is scene/terraincooker.h, the same code the tool uses.
 namespace simulation::terrainbake {
@@ -77,8 +77,10 @@ node_decision examine(
     std::string_view const Type, glm::dvec3 const &Offset, glm::vec3 const &Rotation, bool const Worldspace );
 // one triangle node, in world space, as it is about to be drawn
 void add( std::uint64_t const Key, std::vector<world_vertex> const &Vertices, std::string_view const Material );
-// called once the scenery has been parsed. writes the heightfield and its node table
-void finish( std::string const &Sceneryfile );
+// called once the scenery has been parsed, with every file it included. writes the
+// heightfields, their node table and the manifest of what they were made from; or, when a
+// bake was used, checks the scenery still includes what that bake was made from
+void finish( std::string const &Sceneryfile, std::vector<std::string> const &Included );
 
 } // namespace simulation::terrainbake