Stop Integer#chr from calling a stray byte a character - #7132

…aracter

`inspect` walks the string it prints, and what it meets on the way settles
MRB_STR_SINGLE_BYTE on the receiver: the flag stays set unless a character of
several bytes is copied across whole. A byte that spells no character is
copied one at a time, like an ASCII one, so a string carrying one came out of
`inspect` flagged as holding one character per byte.

That flag is read as leave for stepping through the bytes without decoding
them. `String#codepoints` and `String#ord` then hand the bytes back as the
characters the string does not hold, and `String#scrub` finds nothing to
replace, so what a broken string answers turns on whether `inspect` was
called on it first:

```ruby
s = "\xED\xA0\x80"
s.codepoints         # ArgumentError
s.inspect
s.codepoints         #=> [237, 160, 128]
s.scrub.bytes        #=> [237, 160, 128], where it was [239, 191, 189] * 3
```

CRuby answers those the same way whatever ran before. Ask the walk about the
byte instead of about the character it failed to begin: a non-ASCII byte
leaves the string more bytes than characters whether or not it spells one.

What `inspect` returns is unchanged, and the flag it puts on that return is
too. `\xNN` is what a byte spelling no character is escaped to, so the string
that comes back is still one character per byte, which only a whole character
copied across takes from it. The two answers needed separating to say so.

…cter

Counting characters sets MRB_STR_SINGLE_BYTE when the count comes out equal to
the byte count, and the flag is read as leave for stepping through the bytes
without decoding them. A byte that spells no character is counted as one, so a
string carrying nothing else counts one per byte and set the flag too. Its
bytes then came back as the characters it does not hold:

```ruby
s = "\xED\xA0\x80"
s.codepoints         # ArgumentError
s.length             #=> 3
s.codepoints         #=> [237, 160, 128]
s.ord                #=> 237, where it raised
s.scrub.bytes        #=> [237, 160, 128], where it was [239, 191, 189] * 3
```

CRuby answers those the same way whatever ran before. Every character a
non-ASCII byte begins spells two bytes or more, and a non-ASCII byte that
begins none spells no character at all, so a string holds one character per
byte exactly when every byte of it is ASCII. Ask that instead: the count
already looks for the first non-ASCII byte before it counts anything, so where
there is none the answer is the byte count and the flag holds, and where there
is one the count carries on from it.

`String#length` still counts a byte spelling no character as a character, and
`String#chars` and `String#[]` still give it a position of its own. Only what
is remembered about the string changes, and the walk those two take without
the flag reads such a byte as one character anyway. The test before this one
asks for that.

`RSTR_SET_ASCII_FLAG` is already a second name for setting this flag, and
`String#ascii_only?` sets it exactly where every byte is ASCII, so this is the
meaning the flag's readers were written against. The comment in
`mrb_str_valid_encoding_p` argued from the wider reading and goes.

`Integer#chr` takes any byte from 0 to 0xff. A byte of 0x80 and above
spells no UTF-8 character on its own, so pin what the one-byte string it
returns answers before anything about it moves: its bytes, its length,
the code points and the ordinal read off it, what `scrub` and `inspect`
make of it, the encoding it reports and whether it calls itself valid.

`<<` and `append_as_bytes` reach the same code, so pin what they append
too. Neither takes anything from that string but its bytes.

`int_chr_binary()` set `MRB_STR_SINGLE_BYTE` on whatever one-byte string
it built. That flag says the string holds one character per byte, and
its readers take it as leave to step through the bytes without decoding
them, which is why `RSTR_SET_ASCII_FLAG` is a second name for setting it.
A byte of 0x80 and above spells no UTF-8 character at all, so the flag
was a false statement about every such string, and the string went on
reporting UTF-8 while refusing to read as it.

```ruby
171.chr.encoding          #=> ASCII-8BIT in CRuby, UTF-8 in mruby
171.chr.valid_encoding?   #=> true in CRuby, false in mruby
```

Set `MRB_STR_BINARY` there instead and keep the ASCII flag for a byte
below 0x80. CRuby draws the same line, handing back US-ASCII below 0x80
and ASCII-8BIT above it; mruby has no US-ASCII and reads such a string as
UTF-8, which holds it exactly.

The code points and the ordinal read off the string do not change: they
already came out right, through the branch that byte-indexed strings take
anyway. `inspect` does not change either, since a byte spelling no
character was escaped as `\xNN` before and is escaped as `\xNN` now.

`<<`, `concat` and `append_as_bytes` reach the same helper but take only
the bytes off what it returns, through `mrb_str_cat_str()`, so nothing
they append changes.

`MRB_STR_SINGLE_BYTE` now says that every byte of the string is ASCII,
and ASCII reads as UTF-8 as it stands, so a string carrying that flag is
valid without a walk. Return early on it and remember the answer in
`MRB_STR_VALID_ENC`, which is where the walk would have left it.

A string counted before it is asked about comes in carrying the flag,
which is where this saves the walk. Asking 2000 counted 5 KB ASCII
strings once each: 0.5 ms before, 0.2 ms after. A string that was not
counted first, and one that is not ASCII, are unaffected.

This is sound only because the flag is set nowhere else than on a string
of ASCII bytes. `int_chr_binary()` was the last place that set it on a
byte spelling no character.

Two comments in the tests said that measuring a string of stray bytes
marks it one byte per character. That stopped being so when the flag was
narrowed, and it is what this change now rests on, so drop them. The
assertions under them are what pins it and they stay.