refactor: miniooni should be outside of the engine (#206)

* refactor: miniooni should be outside of the engine

This is part of https://github.com/ooni/probe/issues/1335. We also need
to think whether we wanna keep libminiooni and miniooni separated.

The previous use case for having a top-level libminiooni was that of
enabling others to integrate miniooni into other binaries.

This was usegul when studying internet censorship in Spain in May 2020.

I am wondering whether we should be keeping this complexity. I am not
sure about this and probably we should be killing it.

(In any case, reducing complexity is not the objective of this diff,
since I would like instead to move things around with minimal changes
and make sure we have a ~good repository organization here.)

* fix: import in libminiooni

internal/cmd/miniooni/README.md

@@ -0,0 +1,8 @@
+# miniooni
+
+This directory contains the source code of a simple CLI client that we
+use for research as well as for running QA scripts. We designed this tool
+to have a CLI similar to MK and OONI Probe v2.x to ease running Jafar
+scripts that check whether these tools behave similarly.
+
+See also libminiooni.

internal/cmd/miniooni/main.go

@@ -0,0 +1,21 @@
+// Command miniooni is a simple binary for research and QA purposes
+// with a CLI interface similar to MK and OONI Probe v2.x.
+//
+// See also libminiooni, which is where we implement this CLI.
+package main
+
+import (
+	"fmt"
+	"os"
+
+	"github.com/ooni/probe-cli/v3/internal/libminiooni"
+)
+
+func main() {
+	defer func() {
+		if s := recover(); s != nil {
+			fmt.Fprintf(os.Stderr, "%s", s)
+		}
+	}()
+	libminiooni.Main()
+}