Allow additionally parsing \r newlines in PEM files

[complexspaces]

We (1Password) encountered some users on Linux who were encountering issues using custom certificate roots on their devices, which had been added to the "main" system CA bundle. The root cause of the issue turned out to be rustls-pemfile only supporting UNIX newline endings in parsed files (\n). The certificate bundles sent to us by users though contained one or more PEM objects with \r endings interspersed with ones using \n.

This PR proposes fixing the incompatibility described above by switching to a more lenient line parser function. BufReader::read_until was insufficient for this purpose because it only supports looking for a single needle. Instead, I ported the implementation of read_until out of the standard library and slightly tweaked it to look for more characters. While this uses the more low-level BufReader functions, its been well-tested already and has correct error handling. Thanks to @Ralith for helping point me in the right direction.

Additionally, I believe this is technically more correct based on RFC 7468 (assuming this is the right one 😓) as they call out support for multiple line endings:

Furthermore, parsers SHOULD ignore whitespace and other non-
base64 characters and MUST handle different newline conventions.

A full regression test is included as well. It can be confirmed by undoing the changes to src/pemfile.rs and running cargo test. It should panic with a bogus error. The data file consists of the same Amazon root CA repeated 4 times, but with 2 LF and 2 \r objects.

AFAICT, the only downside of this change is that it has a performance impact, even if almost imperceptible:

Version	Performance
main	1,471 ns/iter
Slow custom read_until, no \r support	1,867 ns/iter (+/- 46)
This implementation	2,842 ns/iter (+/- 146)
memchr2 custom read_until, with \r support	1,491 ns/iter (+/- 12)
libc memchr custom read_until, with \r support	1,517 ns/iter (+/- 15)

A user would need to parse an absurd number of PEM objects to notice the difference, and the only no_std compatible way of regaining it is adding a dependency on the memchr crate, which does not seem to be worthwhile.

[ctz]

I was thinking this might be a regression from ff11ce1, but actually std's read_line is also obsessed with \n: https://doc.rust-lang.org/stable/src/std/io/mod.rs.html#2235-2240 🤨

[complexspaces]

That was my conclusion as well. You have to go out of your way to support other line endings in most functions, with the exception of str::lines which supports CRLF as well.

[cpu]

Thank you! This is a really nice pull request. I appreciate the thorough description + testing methodology.