Implement ByteStr and ByteString types

[joshtriplett]

Approved ACP: rust-lang/libs-team#502
Tracking issue: #134915

These types represent human-readable strings that are conventionally,
but not always, UTF-8. The Debug impl prints non-UTF-8 bytes using
escape sequences, and the Display impl uses the Unicode replacement
character.

This is a minimal implementation of these types and associated trait
impls. It does not add any helper methods to other types such as [u8]
or Vec<u8>.

I've omitted a few implementations of AsRef, AsMut, Borrow,
From, and PartialOrd, when those would be the second implementation
for a type (counting the T impl) or otherwise may cause inference
failures. These impls are important, but we can attempt to add them
later in standalone commits, and run them through crater.

In addition to the bstr feature, I've added a bstr_internals feature
for APIs provided by core for use by alloc but not currently
intended for stabilization.

This API and its implementation are based heavily on the bstr crate
by Andrew Gallant (@BurntSushi).

r? @BurntSushi

[joshtriplett]

Well, that's definitive.

This is ready for review.

[BurntSushi]

This is awesome!

Was there discussion on ByteStr verus BStr? I guess the latter is a bit more opaque, so I think ByteStr is probably the right choice for std. I do like the succinctness of BStr though. (And similarly for ByteString versus BString.)

[Sky9x]

Could an impl CloneToUninit for ByteStr be added? cc #126799

[joshtriplett]

This is awesome!

Thank you!

Was there discussion on ByteStr verus BStr? I guess the latter is a bit more opaque, so I think ByteStr is probably the right choice for std. I do like the succinctness of BStr though. (And similarly for ByteString versus BString.)

I like the succinctness of BStr and BString as well, but others in the libs-api meeting felt those were too opaque. The deciding factor that led me to not push further for the shorter names was that the longer names don't conflict with the bstr crate, making it safer to (for instance) place them in the prelude in the future, and making it easier for crates that need to provide impls for both.

[joshtriplett]

Could an impl CloneToUninit for ByteStr be added? cc #126799

Sure, I can do that.

[Skgland]

I noticed that ByteString isn't allocator aware. Is this intentional? Going from non to one (defaulted) generic argument is making the addition of allocator awareness difficult for String in #101551 (though that would probably only be a problem if ByteString didn't become allocator aware prior to stabilization which is still far out with it not even being merged to nightly).

[joshtriplett]

@Skgland No objection to adding that, but that would be a complex change on top of this, so I would prefer to defer it to another PR.

[BurntSushi]

@bors r+

[bors]

📌 Commit 865471f has been approved by BurntSushi

It is now in the queue for this repository.