MFC r306782-r306783

r306782:
localedef: Fix ctype dump (fixed wide spread errors)

This commit is from John Marino in dragonfly with the following commit log:

This was a CTYPE encoding error involving consecutive points of the same
ctype. It was reported by myself to Illumos over a year ago but I was
unsure if it was only happening on BSD. Given the cause, the bug is also
present on Illumos.

Basically, if consecutive points were of the exact same ctype, they would
be defined as a range regardless. For example, all of these would be
considered equivalent:

<A> ... <C>, <H>  (converts to <A> .. <H>)
<A>, <B>, <H>     (converts to <A> .. <H>)
<A>, <J> ... <H>  (converts to <A> .. <H>)

So all the points that shouldn't have been defined got "bridged" by the
extreme points.

The effects were recently reported to FreeBSD on PR 213013. There are
countless places were the ctype flags are misdefined, so this is a major

fix that has to be MFC'd.

This reveals a bad change I did on the testsuite: while 0x07FF is a valid
unicode it is not used yet (reserved for future use)

PR: 213013
Submitted by: marino@
Reported by: Kurtis Rader <krader@skepticism.us>
Obtained from: Dragonfly
MFC after: 1 month

r306783:
localedef: Improve cc_list parsing

original commit log:

I had originally suspected the parsing of ctype definition files as being
the source of the ctype flag mis-definitions, but it wasn't. In the
process, I simplified the cc_list parsing so I'm committing the no-impact
improvement separately. It removes some parsing redundancies and

won't parse partial range definitions anymore.

Submitted by: marino
Obtained from: Dragonfly
MFC after: 1 month