engine: filter change signals properly

Testing revealed that we were transmitting any change signal that came
in from the bus up to user code, even if the engine in question was not
interested in receiving the signal.

This is a problem in the case that two DConfClient objects exist for
different profiles.  In that case, we'd get crosstalk between the
subscriptions that each client had made and change notifications would
appear in both clients even if the change only affected one.
engine: fix a case of variable shadowing

Testing uncovered a case of a shadowed variable in the signal handling
code of the engine: the object path on which a signal arrived was being
shadowed by the 'path' variable used when deserialising the content of
the signal, causing the signal to fail to be delivered.

Rename the D-Bus path variable to 'object_path' to avoid the issue.
engine: reject junk signals

Check incoming signals for non-sense before bubbling them up to higher
layers.  This will avoid dconf APIs feeding invalid key names to
applications during change notifications in the case that we're fed
invalid data over D-Bus.
tests: test engine processing of signals

Add a testcase to exercise the engine's processing of signals, including
its ability to reject bad data.

This testcase already found several issues with the engine which have
already been fixed in previous commits.