Make the font restoration counters safe against nested project loads

DialogWaiting pumps the event loop while the folios of a project are
built, so a second openAndAddProject() can run to completion nested
inside the first one (drop on another editor window, queued open) and
the plain reset/read counters would then report the wrong numbers.

Replace them with a RAII counting window (FontRestorationScope): the
constructor keeps the enclosing counts aside, the destructor restores
them. The nesting is strictly LIFO - the nested load completes inside
the pump of the outer one - so each load reports exactly its own
numbers, and the early-return paths of openAndAddProject() restore the
outer window automatically.

Suggested by ispyisail in the review of the reporting change.

sources/qetdiagrameditor.cpp

@@ -1171,8 +1171,10 @@ bool QETDiagramEditor::openAndAddProject(
 
 		//Per-project window for the font counters reported below; the folios
 		//(and with them the stored font descriptions) are built between here
-		//and the end of addProject().
-	QETUtils::resetFontRestorationCounters();
+		//and the end of addProject(). RAII, because DialogWaiting pumps the
+		//event loop during the load: a nested openAndAddProject() gets its
+		//own window and this one resumes unharmed.
+	QETUtils::FontRestorationScope font_scope;
 
 	QETProject *project = new QETProject(filepath);
 	if (project -> state() != QETProject::Ok)
@@ -1203,8 +1205,8 @@ bool QETDiagramEditor::openAndAddProject(
 		//Report font descriptions which could not be read as-is (written by
 		//an incompatible Qt version or corrupted), so the user learns about
 		//it from somewhere else than the console. See issue #553.
-	const int salvaged_fonts = QETUtils::salvagedFontCount();
-	const int unreadable_fonts = QETUtils::unreadableFontCount();
+	const int salvaged_fonts = font_scope.salvaged();
+	const int unreadable_fonts = font_scope.unreadable();
 	if (salvaged_fonts || unreadable_fonts)
 	{
 		qInfo().nospace() << "Project font descriptions: "