Remove FromBytesWithNulErrorKind and make FromVecWithNulErrorKind more actionable

[PixelDust22]

#134143 converted FromBytesWithNulError into an enum to address rust-lang/libs-team#493 (CStr::from_bytes_with_nul returns non-actionable error result)

However, the FromVecWithNulError returned from CString::from_vec_with_nul has a similar issue of returning non-actionable error result because you can't get the FromBytesWithNulErrorKind out of FromVecWithNulError.

Additionally, #134143 creates FromBytesWithNulError alongside the existing FromBytesWithNulErrorKind which is exactly the same.

This PR removes FromBytesWithNulErrorKind so that FromVecWithNulError uses FromBytesWithNulError directly. It also adds a new method kind to FromVecWithNulError so that the user can access the underlying error.

This is not a breaking change because FromBytesWithNulErrorKind is private, and we're only adding a method to FromVecWithNulError.

cc @nyurik

[rustbot]

r? @thomcc

rustbot has assigned @thomcc.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[workingjubilee]

r? libs-api

[workingjubilee]

@PixelDust22 You are proposing making an instantly stable change, which is generally not what we do even for small features if we can avoid it.

[PixelDust22]

@workingjubilee Given that #134143 was instantly stable, I don't see why this one couldn't be. This change really should've been a part of #134143.

[workingjubilee]

@PixelDust22 Adding the getter function is a new API.

[workingjubilee]

The change in #134143 was instantly stable because there was no way to feature flag replacing a struct with an enum. Adding a trivial function, however, is something that can be done under a feature flag. Usually doing so is just a formality, but it needs an FCP to add it as stable API in any case.