avoid reposize database locking overhead when not needed

Only when the preferred content expression being matched uses balanced
preferred content is this overhead needed.

It might be possible to eliminate the locking entirely. Eg, check the
live changes before and after the action and re-run if they are not
stable. For now, this is good enough, it avoids existing preferred
content getting slow. If balanced preferred content turns out to be too
slow to check, that could be tried later.

Types/FileMatcher.hs

@@ -96,6 +96,8 @@ data MatchFiles a = MatchFiles
 	-- ^ does the matchAction look at information about the key?
 	, matchNeedsLocationLog :: Bool
 	-- ^ does the matchAction look at the location log?
+	, matchNeedsLiveRepoSize :: Bool
+	-- ^ does the matchAction need live repo size information?
 	, matchDesc :: Bool -> MatchDesc
 	-- ^ displayed to the user to describe whether it matched or not
 	}