{uint->unsigned int}

The former is not standard. Bug triggered while compiling with the latest emscripten
Make dependencies on highgui and ts mandatory only necessary
Do not specify anymore required OpenCV components

Commit 50a8a7b5ba tried to be intelligent and allow compilation without
OpenCV's highgui and ts when they were not needed.

But this broke the compilation with OpenCV 2.4 because the
find_package(OpenCV QUIET COMPONENTS highgui ts) call would overwrite
the previous OpenCV configuration (which is an OpenCV bug, as far as I
understand).

To simplify the situation, we now only call
find_package(OpenCV REQUIRED): all available OpenCV headers/libraries will be
included (which should only marginally impact compilation time), and
guards check that highgui/ts are available if needed.
Removed Pipeable and implementation from interface
Replaced Quad by vector of Point2f
Removed Quad
Added test images from a smartphone
Benchmark uses images of various resolutions

The benchmark aggregates processing times depending on the number of pixels in
the input.
Removed the need to register tags to be detected
Moved edge detection into FindQuads
Moved Refine back to quad-level

Refine still happens before Readbits, which was the important part.
Decoupled DetectChilitags from Registrar
Removed Registrar from detector
The functors now return their output

They can still store it internally and return a reference to it, e.g. to avoid
repeated allocations. Otherwise, we can hope for Return Value Optimisations.
Definitely removed Chilitag and Registrar
CachingFilter avoid flickering detection

CachingFilter basically replaces the persistence functionality of
Registrar/Chilitag (RIP). It simply keeps the position of a tag for n frames
after it disappears (by default, n=5).
CachingFilter comes with unit tests and is integrated into chilitag-detector.
Added TODOs for synthetic integration tests
Merged 'benchmark' and 'integration' tests
Added minimal unit tests for Objects

Also made the corner coordinates coherents for freetags, indepently of whether
objects are detected or not; in the former case, the origin of the marker was
its center, in the latter, the top-left corner. Now the origin of the marker
is the top left corner in both cases.
Added a sample to visualise the 3d pose estimation