fix: unicode on exactly index 7 should not panic

[DanGould]

Problem

A unicode character on exactly the right place (where the previous code used to split the string) would cause a panic.

Fix

Treat the string as unicode in order to compare the scheme, turning the panic into error.

Thank you @lsunsi for opening the original PR

Kixunil#25

[DanGould]

from @nothingmuch:

tl;dr - using [u8] can create an invalid utf8 string if the bad utf8 character is sliced mid way

"using [u8]" was sloppy pphrasing on my part, it's not treating a &str as a &[u8] exactly

the fix, i'm not sure if string.get(...) is the most correct way of doing this

I do believe using string.get(...) is the correct way of doing this

verified the fix in evcxr

[nothingmuch]

ACK, I verified that this implements the correct behavior. FWIW, as a rust n00b the incorrect behavior was not obviously wrong to me at all, perhaps a clarifying comment could improve readability but given that the branch is a PR against bip21 that would need to be in a followup PR i suppose

[DanGould]

tACK on 1b19687 test fails without change and passes with it

[nothingmuch]

from @nothingmuch:

heh, my sloppy phrasing in DMs is so incoherent it almost calls into question my approval

tl;dr - slicing a &str using usize range interprets the usize offsets as byte offsets, but if those fall in the middle of a utf8 character this panics with byte index ... is not a char boundary. get uses the same indexing semantics but returns None instead of panicking if the byte offset is not aligned with character boundary

[DanGould]

Rats. This introduced an MSRV break because the PR ran before that MSRV check was in CI. Deploying a fix