don't unconditionally unparse CHARACTER-SET types into MEMBER types

don't unconditionally unparse CHARACTER-SET types into MEMBER types

  Doing so means dumping a list containing most of unicode for each
  function that return something like

    (code-char (+ <const> <(integer 0)>))

  which has a derived type (CHARACTER-SET ((<const> . 1114111))).

  Instead, pick whichever is more compact, using number of characters
  vs number of character code ranges as the deciding factor.

  This means that users can see SB-KERNEL:CHARACTER-SET types in
  eg. output from DESCRIBE or as return values from
  SB-INTROSPECT:FUNCTION-TYPE -- which is suboptimal, but less bad
  than such types slowing us down as horribly as they do prior to this
  change.

  At some point, however, we should document and export SB-EXT:CHARSET
  or something -- but I don't want to think of the issues associated
  with a public interface right now.