virsysinfo: Be more forgiving when decoding OEM strings

virsysinfo: Be more forgiving when decoding OEM strings

On some systems, there are two or even more 'OEM Strings'
sections in DMI table. Here's an example of dmidecode output on
such system:

  # dmidecode -q -t 11
  OEM Strings
          String 1: Default string

  OEM Strings
          String 1: ThunderX2 System
          String 2: cavium.com
          String 3: Comanche

Now, this poses a problem, because when one tries to obtain
individual strings, they get:

  # dmidecode -q --oem-string 1
  Default string
  ThunderX2 System

  # dmidecode -q --oem-string 2
  No OEM string number 2
  cavium.com

NB, the "No OEM string number 2" is printed onto stderr and
everything else onto stdout. Oh, and trying to get OEM strings
from just one section doesn't fly:

  # dmidecode -q -H 0x1d --oem-string 2
  Options --string, --type, --handle and --dump-bin are mutually exclusive

This means two things:

1) we have no way of distinguishing OEM strings at the same index
   but in different sections,

2) because of how virSysinfoDMIDecodeOEMString() is written, we
   fail in querying OEM string that exists in one section but not
   in the others (for instance string #2 from example above).

While there's not much we can do about 1), there is something
that can be done about 2) - refine the error condition and make
the function return an error iff there's nothing on stdout and
there's something on stderr.

Resolves: https://issues.redhat.com/browse/RHEL-45952
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>