Set up smoke tests for spine-logging

[yevhenii-nadtochii]

During active development, significant changes to the library itself or its build process may produce hardly noticeable flaws that would break logging in clients. And what is more important: they can do it imperceptibly to our in-place tests.

This is less attributable to bugs in the code because library functionality is already tested in-place. It is rather about complexity of the library's roll-out and its usage site: building, publishing, runtime bindings. The library itself has both multiplatform and JVM-specific parts (with possible emergence of new targets), runtime bindings. Clients also may have complicated classpath with other logging facades, bringing their own runtime bindings.

What we need is assurance that the published artifacts are really operational and client calls to log { ... } are not redirected to some sort of /dev/null. So, it is highly desirable to have some sort of "smoke testing" in real conditions, in which nuances of individual modules can play a role in the logging shutdown.

[yevhenii-nadtochii]

The first attempt to implement this was made in base by #800. We should further discuss it in more detail.

@alexander-yevsyukov @armiol FYI