prepend Unicode BOM, improve error handling

- Windows editors do not assume UTF-8 unless they see a Unicode BOM. This
  is prepended now.

- The error handling at various places is improved and simplified.

improve treatment of split strings, add cut label

In some rare circumstances a graphic string has to be split
in 2 smaller pieces which will be printed on different lines.
A new option `--split-bytes SPLI-MIN` gives finer control
under which condition a piece shall be printed.

Furthermore both pieces are labelled with a flag symbol ⚑ (U+2691)
to indicate that they had been cut.

add 2. Unicode-block-filter

- "always pass" characters introduced with version 1.2.0 removed:
  ` !"#$%&'()*+,-./0123456789:;<=>?`
- instead use the new 2. block-filter e.g.:
  `-e UTF-16be,10,U+20..U+2f,U+400..U+07ff`
- speed improvements

improve speed while consuming less memory

Compared to version 0.9.2 this release scans twice as fast.
This is achieved by refactoring some basic objects: The `Finding` object
does not hold a copy of `Mission` data anymore. Instead it points
to a `Mission` object.

process multiple files in the given order on the command line

add a set of 'always pass' characters, reduce false positives when completing strings

1) The following characters do not observe *UNICODEBLOCK*
restrictions and are always printed even if they are out of range:
``\t !"#$%&'()*+,-./0123456789:;<=>?``
(U+0009, U+0020..U+003F).

2) Encapsulate the offset variable in a new `ScannerState` structure.
Add the new variable `completes_last_string` also there. Refactor related code.

3) When strings not fit in the WIN_LEN buffer they are cut and processed later.
The remaining part of the string has to be printed then regardless of its size.
This commit refines the logic of determining this special case in order to
prevent more false positives.

never filter space or tab even with active Unicode-block-filter

add Unicode-block filter