Improve QSPI algorithm on Unix

QSPI uses the wrong algorithm of devices search. In case no any devices
are detected with udev (or with sysfs), starts a search with a filters.
In this case a user gets a list of devices that are not a serial ports,
that is wrong.

The main idea should be in that udev or sysfs are the main sources of
obtaining information. In case they returns an empty list this means
that system has no serial ports.

Algorithm is:

Try to find devices through udev. If it fails (system error or udev is
not present), then try to find using sysfs; otherwise return udev result,
even if it has an empty list. If sysfs is fails (permission denied or
sysfs is not present), then try to find devices in /dev/ as last attempt;
otherwise return sysfs result, even if it has an empty list.

Tested on Linux (with udev, sysfs, filters) using FTDI serial ports.

Change-Id: I0132e27f720b007ea3f4861e9cd7ed77833cff8c
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Make QSPI udev functions more readable

Change-Id: I5c33421338e6a64dbadeb168cf165a84bedec5b9
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>
Improve QSPI sysfs algorithm

Earlier, the algorithm used check for magic keywords (like "usb",
"platform" and so on) in the target path for decision-making what
of device can be skipped or accepted. But this is a wrong approach,
because on different platforms can be different key-words and we
can not know it. So, it is more reasonable to use a different
approach where we make decision by a driver name (by analogy with
current udev implementation). In this case we skip those devices
which has an empty driver name or when a name is equal to
"serial8250".

* When a driver name is empty, then we can be sure that it is
other than serial port device (e.g. as pseudo-terminal, console
and so on). Thus, it is similar to udev devices without a parent,
which we ignore.

* When a driver name is "serial8250", it is equal to "platform"
devices, which we too ignore for current implementation. Though in
a future this can be solved (i.e. we can try to detect a valid
devices based on "serial8250" driver).

Tested on Linux with on-board and USB serial ports using Qt5.

Change-Id: I884ad8f3fddff9487ad4a67c4904b57f62164e00
Reviewed-by: Denis Shienkov <denis.shienkov@gmail.com>