Decouple results matching logic of CompareStoredQueries from FitNesse

This is currently experimental and incomplete effort to decouple dbfit matching logic from FitNesse internals.
Initial focus is to try that on top of CompareStoredQueries though it's likely to appear a bit more generic.

Some rough ideas for now:
 * A `Diff` will be created to encapsulate the matching logic.
 * Events will be emitted to `MatcherListener` to communicate the matching results/progress:
   - endRow(`MatchResult`)
   - endCell(`MatchResult`)
 * `MatchResult<T>` will encapsulate result status and provide access the compared entities:
  - getStatus()
  - getExceptions() //
  - getObject1()
  - getObject2()

* ReportingSystem - wrapper on top of the system which will report the result of the comparison.
* Reporter - intercept Diff events and talk to relevant *ReportingSystem*. (May be doing some some caching and filtering).

Still to do:
- [x] Derive a general interface from `DataTablesDiff` (`diff` method & listeners management)
- [x] Refactor a fixture (CompareStoredQueries) by using `*Diff`
- [x] Consider multi-listeners (add/remove) instead of single one (may help reducing number of forwarded params)
- [x] Break down DataTablesDiff and related test to smaller & tested pieces (it's a bit bulky at the moment) 
- [x] Figure out if it's possible to simplify the type names (too long with generics)
- [x] Refactor FitFixtureReportingSystem tests
- [x] Consider reusing some objects (diffs and diff runners) instead of spawning new instance for each child.
- [x] Test Exceptions and ensure they're handled correctly.
- [x] Ability to inject childDiff into CompositeDiff instead of always spawning it it from inside.
- [ ] Consider if it makes sense to move some interfaces & base classes (e.g. DiffHandler, DiffBase) to api package.
- [ ] Add api for attaching summary to test result in `ReportingSystem`.
- ~~[ ] Try *Null Object Pattern* instead of bare `null` when dealing with missing/superfluous items~~
- ~~[ ] Consider what makes sense to stay in `DiffRunner` and what in the encompassing `Diff`.~~

---
Notes:
* Changed naming notation: use `Diff` instead of `Matcher` for the components which emit detailed different events via listener. Use `Matcher` for something which produces just boolean matches or not result. (Essentially - we can think that `Diff` *is a* `Matcher`).
* Consider which makes most sense:
 - new Diff(a, b).diff();
 - new Diff(a).diff(b);
 - new Diff().diff(a, b);
Currently using diff(a, b) but may be an issue if we want a common interface across {DataTable, DataRow, DataCell}Diff