Make std::io::TempDir::{new, new_in} accept a BytesContainer as a suffix

[csouth3]

This pull request addresses #19437. It was mentioned that Paths can be constructed with any BytesContainer, whereas TempDir's constructors specifically require an &str. There's no reason that TempDir's constructors shouldn't be able to accept any BytesContainer however, so long as the suffix is a valid UTF-8 string.

Closes #19437.

[csouth3]

This is the part that I'm unsure of. I like the idea of changing the parameter from &str to BytesContainer because that matches Path, but ultimately the suffix must still be a UTF-8 string, so the first solution that came to mind was to just return an error like this if that isn't the case, and proceed otherwise. But if we're just converting right to str anyway, does this commit make any sense? Thought I'd throw the PR out to start the discussion though.

[csouth3]

@jmesmon Full disclosure, I'm still running make check on this revision. But this is already looking a lot cleaner to me, is this closer to what you were thinking?
EDIT: make check appears to be happy now.

[alexcrichton]

@aturon and I recently finished taking a close look at all of std::io, but I think we missed TempDir by accident. Would you be ok holding off until we have a chance to review it? I personally prefer not using generics wherever possible, and it seems like somewhat overkill in this case as just because we can accept something doesn't necessarily mean we should take the monomorphization/documentation hit.

[csouth3]

@alexcrichton Totally. I just saw the open issue and thought I'd take a stab at fixing it, but obviously please just do what you find to be best!

[alexcrichton]

Thanks for being patient @csouth3! After thinking about with with respect to rust-lang/rfcs#517 I don't think that this is actually the direction that we want to go in. We've realized that paths are not actually piles of bytes but rather piles of bytes on unix and piles of u16 on windows. This means that eventually this is not the right bound for this function.

Ideally this bound would be AsPath or AsOsStr, but the OsStr one is a bit odd and it's not necessarily a Path but rather a suffix to a path. In light of this I think we'll want to stick to &str for now (the common language of paths as unicode), and we can generalize later if necessary. Thanks for the PR regardless!

[csouth3]

Ah, totally didn't realize the inconsistency between paths on unix/windows. Definitely makes sense to leave it then, thanks for the info!