engine: fix race in match rule adding

Due to the usual way async in dconf works, we can start getting replies
immediately (without returning to the mainloop).  For this reason, we
must be sure that we do not modify the OutstandingWatch structure at any
point after we've issued even one call because the results may already
be coming in.

For this reason, we must add up the 'pending' count in a separate loop
run before we start making the calls.

https://bugzilla.gnome.org/show_bug.cgi?id=724929
gvdb test: avoid infinite recursion

/gvdb/reader/corrupted/7% was failing when run with random seed
R02S2a7b9704dbb5ea704b0d724329af0fbf.

This is a fuzz test, and it turns out that this particular seed ended up
producing a file that was valid, but contained a self-referential table.

The testcase happily recursed though this table's subtable (itself) and
so on, until it ran out of stack space, causing a crash.

This bug would not impact realworld users of gvdb: these users only ever
recurse through tables a finite number of times.  For dconf, subtables
are not used at all.  For GSettings, each schema is a subtable, but from
within that subtable we only lookup values.