Use application name defined in OEM build configuration

That's an undefined behavior.
Since we don't use the return value anyway, we should just use start()

* Don't hide the displayed error directly after showing it
* Don't try to fetch shares when sharing isn't possible

Older ownCloud servers like 8.2.0 used to use integer ids.

This broke when switching to QJson because toString() on JSON
values is strict and returns "" for integers.

Previously this used up some space when there was no icon, leading
to an oddly indented header.

And as a side effect: don't ask for user password when we can't
connect to the server in the first place.

This should help clearly delimiting them in the log for multi-account setups.
This information is already available elsewhere in the log in any case.

Issue #5672

For git hyper-blame support

These would otherwise be line-wrapped by clang-format,
and then consecutive reformattings remove the aligned
comment indentation

Example:

int a; // too long comment

->

int a; // too long
       // comment

->

int a; // too long
// comment

From http://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format

When a new folder becomes selective-sync excluded, we already mark it
and all its parent folders with _invalid_ etags to force rediscovery.

That's not enough however. Later calls to csync_statedb_get_below_path
could still pull data about the excluded files into the remote tree.

That lead to incorrect behavior, such as uploads happening for folders
that had been explicitly excluded from sync.

To fix the problem, statedb_get_below_path is adjusted to not read the
data about excluded folders from the database.

Currently we can't wipe this data from the database outright because we
need it to determine whether the files in the excluded folder can be
wiped away or not.

See owncloud/enterprise#1965

Add a checkbox in the log window as well as a --logdebug command-line
option that should have the same effect.

Issue #5647

This allows using logging rules and custom message patterns with csync.
This also pass the a relative verbosity to the message logger.

Issue #5647

Use qCInfo for anything that has general value for support and
development. Use qCWarning for any recoverable error and qCCritical
for anything that could result in data loss or would identify a serious
issue with the code.

Issue #5647

This gives more insight about the logs and allow setting fine-tuned
logging rules. The categories are set to only output Info by default
so this allows us to provide more concise logging while keeping the
ability to extract more information for a specific category when
developping or debugging customer issues.

Issue #5647

Add the log level and category name in the output. Only output the
thread ID and function name for qCDebug statements as they are not
necessary for general use and make the log harder to read.

Also make sure that the message pattern is set when NO_MSG_HANDLER is
used. Using an environment variable should have priority over it anyway.