Our tests require support for the `stop_event` parameter of`watchfiles.watch` which was introduced in 0.12.

PR#1104 uses a functools.partial as a sub-artifact's_build_func_. When verbose logging is enabled, this caused anexception from `lektor.reporter.describe_build_func`.

This appears to be caused by running watchfiles.watch in a daemonthread.Seesamuelcolvin/watchfiles#128

… reload

Running `lektor build --profile` just runs the build_all under`cProfile`, then prints the stats.The profile information is only really interesting to Lektordevelopers.  Lektor can be profiled directly like this:    python -m cProfile -o prof.out -m lektor build    python -m pstats prof.out

* fix(builder): logic in FileInfo.unchanged was incorrectThis is a longstand bug — there was a race condition.For efficiency, Lektor's build system caches filesystem os.stat() results and(sometimes) checksums of file content.  (For this is uses PathCache tocache FileInfos which, in turn, cache stat and checksums forindividual files.)The FileInfo classes compute defer computation of stat results andchecksums until they are first accessed.`FileInfo.unchanged` is a method that is used to compare a historicalFileInfo which has been retrieved from the build database with"current" state of a file.  The logic in `FileInfo.unchanged` wassubtly flawed.It first compared the `size` and `mtime` of the file. Forregular (i.e. non-directory) files it returned `True` early if thosematched. If they differed it went on to compare checksums, andreturned a result based (only) as the checksum comparison.The logic is flawed: if the size of the file has changed, we can beassured the file has indeed changed, and should return early rightthen — no need to check the checksum.The real bug arises due to the fact that values of size/mtime and thechecksum that are stored in the build database may have be computedand cached at different times. It's possible, in the case that a fileis modified during a build cycle, for the size/mtime stored in thebuild database to correspond to it's pre-modification state, while thechecksum corresponds to its *post*-modification state.  In this case,due to to above mentioned logic flaw, a file will be detected asunchanged, even though its size has changed.There is a comment in the code that indicates the intent was to skipcomputing and checking checksums for regular files if their size andmtime match.  Here, we fix the logic to do just that.  Another optionwould be to check checksums as well (but only in the case that thesize matches.)Going forward, we probably should take care to ensure that whateverwe record about source file state in FileInfo and the build databaserepresents the file state at a single point in time.* fix(builder): fix Builder.touch_site_config* fix(builder): don't ignore `encoding` when opening temp file* fix(builder): fix docstring