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/logiccook.cppm

@@ -9,6 +9,7 @@ http://mozilla.org/MPL/2.0/.
 
 module;
 #include <string>
+#include <vector>
 
 export module eu07.simulation.logiccook;
 
@@ -24,18 +25,16 @@ export {
 // determinism the plan asks for comes from the writer, not from where it is called.
 namespace simulation {
 
-// writes the container next to the scenery. returns false and logs on failure
-bool cook_logic( std::string const &Sceneryfile );
+// writes the container next to the scenery, with the manifest of the Sources it was made
+// from. returns false and logs on failure
+bool cook_logic( std::string const &Sceneryfile, std::vector<std::string> const &Sources );
 // reads a cooked container back and checks it against the events currently loaded. logs
 // every disagreement and returns true only when there are none
 bool verify_logic( std::string const &Sceneryfile );
-// whether the container next to this scenery needs cooking: there is none, this build
-// cannot read the one that is there, or the scenery has been edited since.
-//
-// Edits to an .inc the scenery pulls in do NOT make it stale - only the .scn's own
-// timestamp is compared, because the list of files that went into a load is not kept. Cook
-// by hand with -cooklogic after editing an include.
-bool logic_stale( std::string const &Sceneryfile );
+// whether the container next to this scenery needs cooking: there is none, this build cannot
+// read the one that is there, a file it was made from has changed, or the scenery now reads
+// a different set of files than Sources says it was made from
+bool logic_stale( std::string const &Sceneryfile, std::vector<std::string> const &Sources );
 
 } // namespace simulation