fix: avoid to dump [multi]range as text when binary is requested
If a range has no type information (e.g. is empty and it is a base
class, not a specific range subtype), `upgrade()` would have returned a
text dumper. This would have resulted in protocol violation, such as
requesting unhealthy amount of memory to the backend... and it was
tested too!
Restoring sanity has a drawback. If we have an array of ranges, none of
which has type information, we now fail binary dumping. Previously this
worked, provided that a cast `::int8range[]` was provided, but I think
with an extreme stretch of the protocol: we were producing binary arrays
containing text representation of the ranges.
I don't think the latter is quite valid. So I have a preference for
dropping the feature in exchange of not violating the protocol. We trade
a better dumping of the basic type (an xfail less there) in exchange of
losing the ability of dumping an array of ranges, all empty, using a
cast, in binary format. Binary dump works using a subclass such as
`Int8Range` instead of `Range`.
The lost use case is so marginal that I don't feel the need to document
it. We don't even have documentation for the `Range` subclasses.