Enable binary decoding.

[kousu]

I want to be able to pass binary data through QR codes. qrencode will let me make QR codes like this, but zxing-cpp won't read them: it clips at the first embedded null, and, if iconv is enabled, chokes trying to interpret data as text in some format. There are a lot of fiddly details about transiting between different data encodings and the QR spec doesn't help by being vague on some parts. I've detailed the problems at the sister project https://github.com/nu-book/zxing-cpp/issues/62

I've decided to patch this in a works-for-me kind of way: unmarked encodings are treated as binary and if that's not good enough the higher layers have the source material and can try decoding it themselves.

This adds a single lone test for this case, which also means it adds tests to the project CI config.

[kousu]

It would be good to import https://github.com/nu-book/zxing-cpp/tree/master/test/blackbox to make sure this hasn't introduced any regressions!

jsQR has a huge corpus too https://github.com/cozmo/jsQR/tree/master/tests/end-to-end

[kousu]

For comparison, jsQR outputs both text and binary. You almost do this, returning DecoderResult with both ::getText() and ::getRawBytes(), but the latter is not the same as "binary" because it includes the pre-parsing chunk headers. What I am looking for is something that can give me the unmodified 8-bit payloads of the chunks; your current API gives me. I discovered that compiling with -DNO_ICONV would give me this behaviour, and nothing else would; try it on the test file attached in this PR: the usual zxing'll crop to the first couple bytes because it hits a null almost immediately.

An alternate patch would be to rename ::getRawBytes() with ::getBytes() which behaves the same as jsQR's. But I like having a single output better. I'd rather just be able to control/detect whether I have text or binary.

[gonce30]