wkhtmltopdf produces invalid PDFs that would not open in Chrome

There are several issues with wkhtmltopdf CLI arguments misconfiguration and PDF result processing that lead to producing invalid PDFs that do not open in Chrome, but open properly in Safari.

The underlying issue is related to the fact that by default `-q` argument is not passed to the wkhtmltopdf tool making it produce verbose output, which does not get properly assessed and simply written into resulting PDF. This produces PDF with the following content:

Loading pages (1/6)
[================>                                           ] 27%
(snip)
Printing pages (6/6)
[>                                                           ] Prepari
[============================================================] Page 1
%PDF-1.4   <---------- THIS IS WHERE ACTUAL PDF CONTENT STARTS
1 0 obj
<<
/Title (��

The proposed solution is:
1. Enforce providing `-q` argument to wkhtmltopdf command by always including it in CLI arguments (there is a place in code where this can be done).
2. Remove any content until actual PDF content start (`%PDF-`substring). This will resolve any issues that may be related to any other notices or warnings that cannot be silenced by `-q` parameter (like `QSslSocket: cannot resolve SSLv2_client_method`).

Patch to follow.