qdev: Reject chardev property override

qdev_prop_set_chr() screws up when the property already has a non-null
value: it neglects to release the old value.  Both the old and the new
backend become attached to the same device.  Unlike for block devices
(see previous commit), this can't be observed from the monitor (I
think).

Example: -serial null -chardev null,id=chr0 -global isa-serial.chardev=chr0

Special case: attempting to use the same backend both times crashes:

    $ qemu-system-x86_64 --nodefaults -serial null -global isa-serial.chardev=serial0
    Unexpected error in qemu_chr_fe_init() at /work/armbru/qemu/chardev/char-fe.c:220:
    qemu-system-x86_64: Device 'serial0' is in use
    Aborted (core dumped)

Yet another example: -device with multiple chardev=... (but not
device_add, which silently drops all but the last duplicate property).

Perhaps chardev property override could be made to work.  Perhaps it
should.  I can't afford the time to figure this out now.  What I can
do reject usage that leaves backends in unhealthy states.  For what
it's worth, we've long done the same for netdev properties.

Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20200622094227.1271650-13-armbru@redhat.com>

hw/core/qdev-properties-system.c

@@ -244,6 +244,14 @@ static void set_chr(Object *obj, Visitor *v, const char *name, void *opaque,
         return;
     }
 
+    /*
+     * TODO Should this really be an error?  If no, the old value
+     * needs to be released before we store the new one.
+     */
+    if (!check_prop_still_unset(dev, name, be->chr, str, errp)) {
+        return;
+    }
+
     if (!*str) {
         g_free(str);
         be->chr = NULL;