bug#28489: 27.0.50; eieio-persistent slot type validation should be a bit smarter

[Eric Abrahamsen <eric@ericabrahamsen.net>]

EIEIO object slots can have a :type that looks like "(or thing1 thing2
...)", meaning, obviously, that the value of the slot is legal if it is
of any of those types.

`eieio-persistent-validate/fix-slot-value' makes a first pass over the
slot type specification, to see if any of the "things" are class
symbols. The checking is done by
`eieio-persistent-slot-type-is-class-p', which is able to handle an `or'
statement. The bug comes with:

((eq (car-safe type) 'or)
 ;; If type is a list, and is an or, it is possibly something
 ;; like (or null myclass), so check for that.
 (let ((ans nil))
   (dolist (subtype (cdr type))
     (setq ans (eieio-persistent-slot-type-is-class-p
		subtype)))
   ans))

In effect, only the last element of the `or' statement is checked, which
is obviously a bug. The Right Thing would probably be to return all the
valid class types in the list (with `seq-filter' or its equivalent), and
then change the rest of the code to accept that list.

Otherwise, the spec and value get passed to `cl-typep' directly, which
would successfully validate, except that "value" is still an object
construction form, not a constructed object.

It just seems like there's a lot of overlap between this and `cl-typep'.
And, coincidentally, I'm getting bug reports about the very slow
performance of `eieio-persistent-read'! I wonder if `cl-typep' could be
taught to handle some more of these cases.

The minimum fix seems to be to have
`eieio-persistent-slot-type-is-class-p' return a list of classes when
necessary. I can take a whack at a patch for that, if acceptable.

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.21)
 of 2017-09-17 built on clem